MrDaleSmith → created an issue.
This is caused by the module having been updated to be PHP 8 only - the syntax for commas in parameter lists is incompatible with PHP 7.
Works for me too.
@ravi-kant I know how to override a library: the issue here is the module is too opinionated about CSS, not that there aren't ways of working around it.
@ravi-kant I'm overriding in my theme's CSS, but how ever you do it I still have to, so that doesn't resolve the actual issue.
I have a site where the node aded form for a content type has every element inside a collapsed fieldset: applying the patches in #100 and #116 still generated JS errors that silently prevented form submission when I trry to submit the form without filling anything.
The patch on #15 applies cleanly to the dev version of the module, as is standard practice for Drupal patches.
just adding a note to say if you add Ultimate Cron to your site, you can disable individual cron jobs as required.
Patch to resolve issue.
MrDaleSmith → created an issue.
The reason this is failing is because if the user does not have the "reset" permission for either all vocabularies or the specific vocabulary being looked at, the core overview form does not add the tabledrag data into the form (core/modules/taxonomy/src/Form/OverviewTerms::buildForm 443-471.
I'm not sure how this should be resolved in the module, but a workaround is to grant users both the reorder and reset permissions if you want them to be able to use the drag and drop reordering.
First attempt at a patch to resolve the issue.
MrDaleSmith → created an issue.
Yeah the error is caused by an update to the client to v3.4, which according to https://github.com/algolia/algoliasearch-client-php/issues/720 is not an official or supported release yet. This might require a more specific version constraint in this module to prevent the error.
Those are the steps: use the module on PHP 8.2 and it generates a PHP notice.
First go at a patch to remove the workaround.
MrDaleSmith → created an issue.
Applied patch and it allows me to move to CK Editor five and embed videos into the WYSIWYG.
Not sure that one applies, so here's another in case
Rerolled to apply to current version 2.0
Attempting to reroll again
Dave Reid → credited MrDaleSmith → .
Just for anybody whose update to D10 is blocked by this module, it might be worth checking the module's code: the module is basically one-line of code that is easily replicable if you have any custom modules or themes in use on your site to put it in and need to get to Drupal 10 quickly.
That'd be a call for the maintainers, but seems like overkill to me :)
I believe that's unrelated to this issue and has been raised previously in https://www.drupal.org/project/simple_menu_icons/issues/3328904 🐛 Error: Undefined constant "FILE_STATUS_PERMANENT" in simple_menu_icons_menu_link_content_form_submit() Fixed
Rebased against 8.x-2.x branch
MrDaleSmith → made their first commit to this issue’s fork.
Patch no longer applies, so I rerolled in a fork and opened an MR
MrDaleSmith → made their first commit to this issue’s fork.
MR opened for proposed change.
MrDaleSmith → created an issue.
Had issue; applied patch; don't have issue. Cheers!
You can use the dev version of the module, or get a patch from the MR by adding .patcxh to its URL: so https://git.drupalcode.org/project/autoban/-/merge_requests/7.patch
We've had a fair amount of time to get used to it, though, where we didn't with other changes like namespacing and plugins. I'd be interested to find out how many projects on d.org have dependencies in their info.yml files that aren't in their composer.json files - can it really be that big a number given that we never told anyone we'd use info.yml for composer dependencies?
I still think it's a confusing Drupalism to be parsing composer dependencies from the info.yml files. Composer handles dependencies and where they should be downloaded from really well and all our documentation says "Use composer to manage your dependencies". It just causes issues to say "Drupal uses composer to manage dependencies, kind of - sometimes we think it's best to ignore it and use something else".
Had this issue: used the change in the MR and the issue was resolved.
I may be quick, but I don't think I can help: I've just tested composer require drupal/patreon on a clean Drupal 9.5.7, PHP 8.1.16 installation using composer 2.5.5 and had no problems with it.
I can't think of what could be going wrong: the Patreon API will throw an error is the URL you send it to redirect to doesn't match the one in the client set up on their side, so if you're getting redirected back to your site that should all be correct. It sounds like the cause of your issue is with the autoload functionality that Drupal/composer use to ensure all libraries downloaded through composer are available to Drupal, but the issue appears to be specific to your set up. Have you tried testing locally with ddev or similar to see if you can find the source of the problem?
The only other thing that occurs to me is that the /oauth route is only available to users with the 'administer patreon' permission, but that wouldn't return a 404 or log a missing library issue.
I'm afraid I can't confirm this is an issue with the module, so I'm going to close as won't reproduce. If you find differently, please do reopen and I'll investigate further.
Updated patch as it no longer applied to the latest version.
It sounds like you haven't installed the module using Drupal's composer integration: composer require drupal/patreon being run in the root of your Drupal install. Would that be the case?
I suspect that you've manually put the module in modules/contrib and then run the composer install there, which won't put the required patreon library in the right place for Drupal's autoload to discover it, causing the error you've seen.
If that's not the case, can you give me the steps to recreate the error, starting with downloading the module and going from there?
The required br33f/php-ga4-mp library is listed in the composer.json file, and
new BaseRequest($options['cid']);
in ga_push/inc/ga_push.php_mp.inc requires anyone using the function to set their Google Analytics client id in the options even if using the default id that the code itself has loaded from configuration a few lines before. I've attempted to fix these in the fork, but for some reason I can't get access to it, so I'll have to leave it for someone else to resolve.
Works for me.
MrDaleSmith → created an issue.
We accidentally had the social share block displaying without path restrictions, which means even with the fix in place we still got a fatal error on the user edit page. A ++ for the fix in #4 working: because it doesn't assume that $title will only be an array for the two specified routes and will always turn it into a string if it is an array, it should be more robust.