This worked well. Thanks for the patch.
Worth noting that a related issue was down to bogus whitespace at the end of the file, just after the final closing tag. The XML parser didn't seem to like that either.
This plugin worked really well as there is ambiguity with importing dates in the format dd/mm/yyyy
Thanks @tostinni for the work on this. If I had a better understanding of writing tests I'd sort this out!
I'm seeing a similar problem if some of the XML elements are missing. Tried the latest MR/patch at ✨ Improve handling of empty data Needs review and didn't improve things. May actually be a Feeds issue, rather than Tamper though
I applied the current patch via altering repositories section of composer.json
"repositories": [
{
"type": "vcs",
"url": "https://git.drupalcode.org/issue/db_maintenance-3429787"
},
{
"type": "composer",
"url": "https://packages.drupal.org/8"
},
Then running composer require drupal/db_maintenance:dev-3429787-automated-drupal-11
Whilst Composer allows the module to be downloaded, the file db_maintenance.info.yml doesn't have '11' in its core_version_requirement
Worth noting that the additional repository with the forked version of the module must come before the main repository for Drupal entry in composer.json, ie:
"repositories": [
{
"type": "vcs",
"url": "https://git.drupalcode.org/issue/simplify-3478246.git"
},
{
"type": "composer",
"url": "https://packages.drupal.org/8"
},
...
Otherwise Composer will prioritise the standard distribution of the module (and the install will fail).
Thanks for your work on this @mably and your really simple way of applying this to D11 (no need for Lenient and patches 🙂). Seems to work OK - but I've only just installed this on a currently empty D11 install, so need to do a more thorough review.
Love this module. +1 for commit to DEV
I tried the MR and worked fine for me. +1 for RTBC
I had to manually apply the patch (thanks for your work @yujiech), but the functionality generates only the 2 checkboxes, and hides the graph :(
Patch attached for anyone keen to look at this further. Tried in Charts 5.0.13 and D10.3
Correct the score value at end of first condition (answered > 0)
I like the logging added at #36.
I can't see any reason why this shouldn't be RTBC. Enough users have found the earlier patch at #11 to be beneficial and have not flagged up any problems.
I'm seeing this too:
* In Chrome - I see both date and time icon pickers
* In Firefox, the date time picker is visible, but the time isn't
* In Safari, neither icons are visible.
I think it's an HTML5 implementation in the browser limiting the visibility of the icons, not something that Drupal can deal with out-of-the-box: https://caniuse.com/input-datetime
I agree. The location of the Delete button in the sidebar is poor UX, as it's too instinctive to hit that button when adding a note to the revision log or changing state. Should be elsewhere, or added to the save/preview button cluster which is more consistent with other Drupal UX.
The patch is perfect (thanks @zarexogre), and I will probably use this as a default in all my builds.
@saschaeggi - can't find any reference to a split button anywhere
@TimeFor - thanks for solution. I'd seen the error and it was exactly that issue where I'd transferred databases between environments. Worth noting as a potential Drupal general problem.
It was a case of looking in users_field_data table and comparing UIDs to the users table and seeing where there was a mismatch. In my case it was the highest UID in the users table that was erroneous - just edited the users table in PMA and altered the relevant UID value to 0
I've been seeing the same error having created, altered and deleted some transitions on a fresh 10.2 site. The patch at #11 allowed permissions to be updated without the error. Thank you for the patch
@saschaeggi - it's a complex D10.2 site but the issue seems to be down to the margin-bottom value calculated in js > tableheader.js updateTableHeader function by the line:
tableHeader.style.marginBottom = `-${el.querySelector('thead').getBoundingClientRect().height + 1}px`;
In my instance the THEAD has a height of 54px, so the marginBottom value should be 55px, but the JS implements this as in inline style value -54px in the enclosing table. If this value is changed to 20px then the 2 table headers are visible, but the upper, sticky header is above the system 'Filter' input box and it's at least usable.
For the moment I'm just going to use some hacky CSS in sites/default/files/gin-custom.css to get around this. Will probably break something else...
.user-admin-permissions .gin--sticky-table-header{
margin-bottom: 55px !important;
}
(Sorry about the !important value. I know)
I can't seem to use the latest MR (cannot apply diff as patch), however the patch at #3273358-146: CKEditor 5 support for Content Templates → applies correctly to latest DEV release and appears to function correctly. Thanks for everyone's work on this - it's a great module.
Worth pointing out this alternative module: https://www.drupal.org/project/ckeditor5_template → - similar functionality (and D10+ ready), but doesn't have a UI to create templates: the templates are built in a JSON file with embedded HTML.
I've applied MR404 mainly to address sticky headers on the permissions page (lots of related - closed - issues), but I actually see 2 sets of table headers with the patch applied. The upper header obscures the 'filter' box on permissions on page load, but is the header that remains sticky when I scroll down.
Whilst this was postponed and kicked into the long grass 2 years ago, I think it warrants a little more inspection as an issue.
The addition of the 'core/once' library in Gin module 🐛 Resolve Missing Dependency 'core/once' in Gin_accent Library Closed: duplicate hasn't changed the error on login.
I can only replicate the error described in this thread with Gin Login enabled, and JS aggregation on. When the error occurs, Console flags up an error: Uncaught TypeError: Cannot set properties of undefined (setting 'human') indicating a problem linked to antibot.js - with the aggregated JS error at https://git.drupalcode.org/project/antibot/-/blob/df2cc22726e9f88a39f316...
drupalSettings.antibot.human = false;
Which seems odd, as this line is initialising an object. I changed the way human is initialised:
drupalSettings.antibot = {
human: false
};
And whilst the Console error went away (and no other JS errors), the Antibot 'Submission Failed' error page returned, preventing login.
I thought the problem might be down to using a password manager to login, but the JS is capturing mouse moves after form is submitted (see JS code 21-38).
I'm stumped - don't really think this is a JS error. Only current option in production is either not use the module, or remove the user_login_form from the Antibot settings.
The MR isn't functional, as too much code references functions that were deprecated in D8+. Thank you for your work.
I think the easier option than this approach in the module is just some basic CSS in your theme, eg:
a[href$=".docx"]:before {
content:url(../icons/ms-word.png);
}
https://www.drupal.org/project/file_resup → is now at a Beta release for D10 and facilitates a Dropzone style drag and drop UI (and some other nice features). The module could do with some testing and review.
This issue has been live for over 7 years now: it's probably fair to say that the desired functionality will never be delivered in the DropzoneJS module.
I'm not sure the ID issue is the culprit. I'm using the Gin Login module and don't see any duplication of IDs, although I wonder if that's common to other users who flagged this issue?
Same problem. Fine on local dev; locked out of prod. This should be a great module, but it will have to be removed for the moment. Cannot see any clear reason why the login form is such an issue.
Just applied patch against a D10.2 site. Works fine. Thank you
robcarr → changed the visibility of the branch 3404964-entity-queries-to to hidden.
Using the basic features of the module is straightforward if you have set up a custom search page in Views which does a Fulltext search.
In Search404 settings, enable "Do a "Search" with custom path instead of a Drupal Search when a 404 occurs" then set the path to be something like: custom-search?search=@keys - depends on how you've configured your View.
Would be nice if a lot of other features worked with the Search API Database though...
@alison - the error I'm seeing is generated by Composer. I've not tested the module, as it cannot be installed without the various hacks: it is important for this to work on a production site that was recently migrated to D10 (so this site currently has no DOI lookup).
From the WSOD error I'd assume there's an error with the function getLastRequestTime() which must be linked to the class AbstractRateLimitProvider (presumably somewhere in the Guzzle world, but I can't track that down...), which may mean there's an error creeping in because this module's dependencies are now required to support multiple versions.
I still seeing the psr/cache error with the 'core-recommended' clean D10.1 installation.
I'm sceptical about saying that this bug is 'fixed' if it doesn't work with the recommended D10 distribution.
Thanks for your work @uberengineer.
However, I cannot get the module to install via Composer. I've installed Lenient and Composer Patches (see https://github.com/mglaman/composer-drupal-lenient) and tried installing the DEV branch of Bibcite Crossref with the MR applied as a diff patch, but the error traces (as at #7) are still present.
I see your changes are now in the main branch of renanbr/crossref-client so I'm assuming we need to wait until there's a new formal release of crossref-client before installation of bibcite_crossref will work.
I've just set up a bare D10.1 site (to replicate the problem) and the DEV release cannot be installed with Composer. Same error traces as reported in #7
Having taken a hit on DOI lookup functionality, I disabled this module to allow the site to be upgraded to D10.1 (and removed from Composer.json).
I'm not able to download the module via Composer:
`composer require 'drupal/bibcite_crossref:2.0.x-dev@dev'` results in
Your requirements could not be resolved to an installable set of packages.
Problem 1
- cache/array-adapter[1.0.0, ..., 1.0.1] require php ^5.6 || ^7.0 -> your php version (8.1.16) does not satisfy that requirement.
- cache/array-adapter 1.1.0 requires psr/cache ^1.0 -> found psr/cache[1.0.0, 1.0.1] but the package is fixed to 3.0.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- cache/array-adapter[1.1.x-dev, ..., 1.2.0] require psr/cache ^1.0 || ^2.0 -> found psr/cache[1.0.0, 1.0.1, 2.0.0] but the package is fixed to 3.0.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- renanbr/crossref-client[1.0.0, ..., 1.1.0] require guzzlehttp/guzzle ^6.2 -> found guzzlehttp/guzzle[6.2.0, ..., 6.5.x-dev] but the package is fixed to 7.8.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- drupal/bibcite_crossref dev-2.0.x requires renanbr/crossref-client ^1.0 -> satisfiable by renanbr/crossref-client[1.0.0, 1.1.0, 1.1.1].
- drupal/bibcite_crossref 2.0.x-dev is an alias of drupal/bibcite_crossref dev-2.0.x and thus requires it to be installed too.
- renanbr/crossref-client 1.1.1 requires cache/array-adapter ^1.0 -> satisfiable by cache/array-adapter[1.0.0, ..., 1.2.0].
- Root composer.json requires drupal/bibcite_crossref 2.0.x-dev@dev -> satisfiable by drupal/bibcite_crossref[2.0.x-dev (alias of dev-2.0.x)].
Add in dependencies `composer require 'drupal/bibcite_crossref:2.0.x-dev@dev' -W` results in:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- rtheunissen/guzzle-rate-limiter[v1.0.0, ..., v1.0.1, v2.0.0] require guzzlehttp/guzzle ~6.0 -> found guzzlehttp/guzzle[6.0.0, ..., 6.5.x-dev] but these were not loaded, likely because it conflicts with another require.
- renanbr/crossref-client[1.0.0, ..., 1.1.0] require guzzlehttp/guzzle ^6.2 -> found guzzlehttp/guzzle[6.2.0, ..., 6.5.x-dev] but these were not loaded, likely because it conflicts with another require.
- drupal/bibcite_crossref dev-2.0.x requires renanbr/crossref-client ^1.0 -> satisfiable by renanbr/crossref-client[1.0.0, 1.1.0, 1.1.1].
- drupal/bibcite_crossref 2.0.x-dev is an alias of drupal/bibcite_crossref dev-2.0.x and thus requires it to be installed too.
- renanbr/crossref-client 1.1.1 requires rtheunissen/guzzle-rate-limiter ^1.0 || ^2.0 -> satisfiable by rtheunissen/guzzle-rate-limiter[v1.0.0, v1.0.1, v2.0.0].
- Root composer.json requires drupal/bibcite_crossref 2.0.x-dev@dev -> satisfiable by drupal/bibcite_crossref[2.0.x-dev (alias of dev-2.0.x)].
I also tried deleting composer.lock as it looks like there are circular dependencies, but that's opened up a different can of worms.
Unless it's just me (and it could be, but there are not many users of this module), @AardWolf I'd still say this is a Critical Bug.
Probably more appropriate to change this to 'Bug report' as the formal release of this module is tied to D9 which has reached end of life, and AFAIK it doesn't appear to be possible to install on D10...
I've done the same and still have warning message. Not sure if the current session needs to end for the warning to go away. I tried deleting the domain+session cookies but made no difference
Thanks Rishi. Seems that this is a common problem on many modules running on D10
Have created an issue at https://github.com/renanbr/crossref-client/issues/18 - with a patch to change the version of guzzle to ^7.5 but I don't seem to be able to use Lenient (https://github.com/mglaman/composer-drupal-lenient) to apply it.
Seems only way forward is to uninstall this module to get site running in D10
The DEV release appears to support D10, but I'm struggling to upgrade from D9 using the DEV release (which has the various patches applied from 📌 Automated Drupal 10 compatibility fixes Needs review due ti module dependencies
When updating via Composer I have a stream of problems, mostly due to the dependency on renanbr/crossref-client which has a dependency on guzzlehttp/guzzle ^6.2 or ^7.4. In D10 guzzlehttp/guzzle is fixed at ^7.5 by drupal/core
https://github.com/renanbr/crossref-client/blob/main/composer.json list the dependencies, but if I run `composer why guzzlehttp/guzzle` (without being able to download either drupal/bibcite_crossref:2.0.x-dev@dev or renanbr/crossref-client via Composer) I get:
drupal/core 10.1.6 requires guzzlehttp/guzzle (^7.5)
drush/drush 12.4.2 requires guzzlehttp/guzzle (^7.0)
php-http/guzzle7-adapter 1.0.0 requires guzzlehttp/guzzle (^7.0)
(Also tried drupal/core:^10.0)
I can download version 0.1.0 if I run `composer require renanbr/crossref-client` but this is a pre-release version that has no dependencies on Guzzle, so doesn't meet the requirements of bibcite_crossref
Is there anyway to get around the dependency version issue on renanbr/crossref-client or guzzlehttp/guzzle? There appears to be no way to download and install this module in D10 (hence change issue priority to Critical).
Note that the patch at #3336179-8: Drupal 10 compatibility → will only work against the DEV release, not the 8.x-1.2 version
Thanks for the patch - resolved the problem (below) for me, although I was using latest release - so line numbering different - and my error was based on Views [another non-fieldable entity]
Error: Call to undefined method Drupal\views\Entity\View::getFieldDefinitions() in shorthand_metatags_alter() (line 114 of modules/contrib/shorthand/shorthand.module).
The blocker if you are trying to prep a site for D9 > D10 upgrade is guzzlehttp/guzzle. Run `composer why guzzlehttp/guzzle` and you can see that drupal/core-recommended (9.5.11) requires guzzlehttp/guzzle (~6.5.8) (whereas drupal/core is more flexible as it requires guzzlehttp/guzzle (^6.5.8 || ^7.4.5)).
Only solution is at #3283651-50: Drupal 10 compatibility: changing php-http/guzzle6-adapter dependency into php-http/guzzle7-adapter → (#50) to modify your composer.json file
Previous patch does not apply :(
Patch to look at D10 compatibility and address all coding standards issues. Would welcome a review and maybe some additional work will be required on tests.
Have rolled patch agains 1.0-alpha5 as it's much more current then DEV release.. although I suppose that might fail automated tests in itself
Running the module through PHPCS it's riddled with (mostly trivial) coding standards errors. I'll try and do what I can do work on these, but I struggle with tests, so might need support
Other issue I've noticed is that current formal release (8.x-1.0-alpha5) was released 19 January 2022, whereas Dev release is far older (over 2 years ago: 24 May 2021). So I'm going to base all my updates on the alpha5 branch
Sorry, this module needs some basic work to pass tests. Mostly code formatting...
Just upgraded a couple of sites to D10 and this patch seems to work fine. Thanks for your work
It's impossible to upgrade a site to D10 without this patch. Thanks for your help @markdorison
Previous patch failed due to unrelated coding standards.
Still relevant all these years on. PHP error only seems to appear when View not properly configured
Thanks very much @milindk - I should have thought about altering the parse mode
Can Views be referenced using this form element? I've tried (using '#target_type' => 'view', and the filtering/selection works fine but the return value isn't a URL, but I a string formatted as entity:node/VIEW_NAME instead
Like the idea of this patch and it's a shame the functionality isn't already there (pretty much every other entity type can be matched). Doesn't apply to 6.0 branch.
@eiriksm the patch worked well at the time, but - 3 years on - not sure if it still works. I didn't want to RTBC the patch at the time as nobody else had tested it. The site/project I was working on was cancelled and unfortunately I've had little to do with Commerce since.
I've raised this issue multiple times with SG, in the hope that they'll move away from [the insecure] PHP7 sooner. But I remember having similar conversations with many other hosts' tech support regarding PHP5 (feels like yesterday), and they did upgrade... eventually
I think most of their client base is using Wordpress and it feels like Drupal isn't really a priority. Most of the sites hosted by SG are probably still running PHP7, and SG will be using that metric to drive their upgrade path. However, among the cheaper end of the hosting marketplace, SG seems good value.
@Problue Solutions - I think I've addressed point geometry imports at #3381048-4: Unable to Import via Feeds → .
Documentation or UI could be a bit clearer, but it does work if you know how to use the mappings. Geofield import will work with Feeds for single points if the 'Geometry' value is left to 'Select a source' in the Feeds mappings, and the lat/long values are mapped correctly.
@itamair - thanks for the reply - I hadn't appreciated that the fields within the Geofield could be just left blank: I've just tested it with the location>Geometry left to 'Select a source' and the multi-value issue during import is gone. Documentation (or the UI?) could be a little clearer in that all 3 parameters do not need to be selected, but hopefully this post will act a reference for those that solve the problem by Googling.
For reference, I had used feeds_ex module with the following JSON used:
{
"attributes" : {
"OBJECTID" : 2,
"latitude" : 54.98569782,
"longitude" : -3.249683852,
"site" : "Car Park",
}
},
Mapping the lat and long values to the Centroid Lat/Long worked just fine.
Thanks for your work on the module.
After a bit of trial and error, I have successfully mapped lat/long from a JSON source into a content type with a single value Geofield.
The following settings for the 3 values of the location (Geofield) for a single point address:
- Map the values for latitude and longitude to Feeds 'Temporary targets' (so that tokens are generated)
- Latitude - should be empty. I mapped a blank source to this value (as Feeds Tamper didn't seem to implement NULL effectively using a 'Set value or default value' tamper.
- Longitude - should be empty (as above)
- Geometry - use a Feeds Tamper rewrite with the previously generated tokens:
POINT ([longitude] [latitude])- note order of lat/long and a space (not a comma)
If either of the lat/long values [in the Geofield] are anything other than NULL in the Feeds mapping, Feeds attempts to create a second instance of the location, hence the cardinality errors during the import. I don't understand why Geofield does this, nor why a location cannot be imported using just lat and long values (and ignoring the geometry value).
It might be useful to refer to this in the documentation of the module. Alternatively, simplify mapping of Geofield for single point imports.
I'm seeing exactly the same problem as reported by @Problue Solutions in #22, and do not understand the proposal in #23, specifically:
if you are importing Geometries use just the geometry property in the mapping (and leave unset the Lat and Lon selects).
I have source values in JSON for latitude and longitude, which can be Feeds mapped to location > Centroid latitude and location > Centroid longitude. I've set the default value (with Feeds Tamper) for location > Geometry to null as I'm only importing point locations.
However, when running a feeds import (as reported in #22) the import fails stating that:
...failed to validate with the following errors:
location (location): location: this field cannot hold more than 1 values.
So the import will only work if the Geofield field storage is set to a multivalue.
Feels related to the way this thread evolved, but should a fresh issue be raised? (I'm probably answering my own question here)
Thank you for the work on the patch. I've just implemented it, as I'd had to recently upgrade the server to PHP8.1 and sending out Simplenews caused Cron runs to fail.
Probably worth committing the patch ASAP, as there's at least 18 months' life left in the 7.x version of this module. Certainly warrants the 'Critical' priority.
Thanks for all the suggestions - they had been working just fine.
Despite having PHP8.1 running in the CLI (and for the server), I'm now seeing the following error on Siteground when trying to initiate Drush scripts:
Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.1.0". You are running 7.4.33. in /home/customer/www/SITE/public_html/vendor/composer/platform_check.php on line 24
I have changed my site's composer.json "platform-check": false but that doesn't seem to have prevented these errors.
The patch at #37 has helped me on D9.5
I'd been trying to uninstall modules and getting lots WSOD/errors:
TypeError: Drupal\Core\Entity\ContentEntityStorageBase::onFieldDefinitionUpdate(): Argument #1 ($field_definition) must be of type Drupal\Core\Field\FieldDefinitionInterface, null given, called in web/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php on line 222 in Drupal\Core\Entity\ContentEntityStorageBase->onFieldDefinitionUpdate() (line 546 of web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php)
This patch works just fine (tested on 9.5.x and 10.1). Make sure if you are using the Search API exposed form that you've either uninstalled the core Search module or addressed any conflicts with routing, URLs etc
Actually, patch #2 didn't apply correctly against D10.1. Re-roll attached. UI is functional but the intended breadcrumb is not rendered.
The patch #2 applies to 10.1 (although testing flags up a few coding errors), but as @almador reports it does not work
Sorry about that. Some gremlins crept into my IDE. Re-roll attached
Patch applies and JS/console error is gone
Updated patch attached to incorporate the automatic Rector patch, plus the change suggested by @Libbna
You'll need to clear Drupal caches plus also the browser cache. Works just great in D10.1
Would be great to commit this, so that a D10 compatible release can be made
And again... so sorry
Sorry - bad patch...
I'm seeing this problem in D10.1 too, and it's clearly a problem generated by other modules.
A lot of the JS has been removed in D10, so the patches above that people have put a lot of work in won't apply. With the caveat of 'I've absolutely no idea what I'm doing' the attached patch stopped all the console errors and - in my case - has allowed the modals for Views to pop-up again. It may have stopped something else really significant working, but I'll revisit if that's the case.
The latest patch from MR9 works fine against the latest Dev release of Honeypot, and with D10.1-rc1
Updated patch attached
If accessCheck(TRUE) is inserted into the relevant query in the file_entity.install file, then the update runs fine:
/**
* Update pathauto to enable path field for file entity type if there are
* file aliases or patterns.
*/
function file_entity_update_8201() {
if (\Drupal::moduleHandler()->moduleExists('pathauto')) {
$file_patterns = \Drupal::entityTypeManager()->getStorage('pathauto_pattern')->loadByProperties(['type' => 'canonical_entities:file']);
$file_aliases = \Drupal::entityTypeManager()->getStorage('path_alias')->getQuery()->condition('path', '/file/%', 'LIKE')->accessCheck(TRUE)->count()->execute();
if (!empty($file_patterns) || $file_aliases > 0) {
$config_factory = \Drupal::configFactory();
$config = $config_factory->getEditable('pathauto.settings');
$enabled_entity_types = $config->get('enabled_entity_types');
$config->set('enabled_entity_types', array_unique(array_merge($enabled_entity_types, ['file'])));
$config->save();
}
else {
\Drupal::messenger()->addMessage(t("Files no longer have an alias field by default, enable it in the pathauto settings if you wish to use that."));
}
}
}
The patch applies although when running the database update 8201, it generates the following errors:
Entity queries must explicitly set whether the query should be access checked or not. See Drupal\Core\Entity\Query\QueryInterface::accessCheck().
The patch at #16 worked for me: D10.1-beta1; PHP 8.1.6; Adv link 2.1.1; Chrome 113.0.5672.126
Note: I cleared Drupal cache and the browser cache
Thank you for all the work on this issue. I've tried most of the recent patches against D10.1-beta1, and cannot get them to apply.
There's a dependency on Commonmark 2 with the Migrate Markdown to HTML module ( https://www.drupal.org/project/migrate_process_markdown_to_html → ), so I'd say this feature is quite important
I have this running on D10.1. Doesn't seem to be any other issue preventing it working with D10...?
Thank you for the work on the patch.
The patched module applies to D10.1, but I don't seem to be able to enable the 'Markdown' filter with CKEditor5. All the text is present in the text format config page, but the toggle is disabled
Is there a possible filter or config clash preventing this?
I'm seeing the problem on PHP8.1 - patch works (which is in dev release), but still isn't in formal release of OG
I'm seeing this issue on a 9.5.7 site with 8.x-1.3 running (have also tried dev branch). It's clearly a module clash or site config issue, as I have Coffee running just fine on other D9.5.x sites.
I had noticed that the following errors were in the log:
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "node_type" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 139 of/EntityTypeManager.php).
After a bit of investigation, the site I'm having problems with only has custom entity types and it seems that there is an implicit dependency on the Node module being enabled in Coffee to work correctly. Looking through the code in src/Controller/CoffeeController.php there are a few implicit dependencies that are probably enabled on most Drupal sites by default, including Node and Menu. To be thorough, maybe the module should add the relevant dependencies in info.yml, or maybe split the 'Node' aspects of Coffee into a submodule.
Probably doesn't help many others following this issue...
nironan's suggestion at #3 has worked really well for me, although worth noting that the JS has to be executed in the footer for the document.body.appendChild(scriptTag); to work.
I had to add Plausible to a D7 site (which only has a D8+ module), couldn't add the recommended snippet to the theme, so used the following JS executed inline in the footer (following provided to those landing here via a search listing):
var scriptTag = document.createElement('SCRIPT');
scriptTag.src = 'https://plausible.io/js/script.js';
scriptTag.dataset.domain = "MY DOMAIN";
scriptTag.async = true;
scriptTag.defer = true;
document.body.appendChild(scriptTag);
Tested on PHP 7.4 and PHP 8
Can't see many others reviewing this, so changing to RTBC. Thanks for your work @joelpittet
Bit lost with this issue. I still see the problem in 9.5.9 site with 8.x-1.0-rc1, although could be related to 🐛 Default CSS Conflicts With Front-End Theme Closed: cannot reproduce
The patch at 17 may well have been committed, but the code (snippet below) is back in the latest release
// Are we relevant?
- if (!_gin_toolbar_gin_is_active()) {
- return;
- }
If the approach at #17 is still valid, I've attached an updated patch
The patch at 11 works fine.
The patch at 15 is really helpful, but not necessarily relevant to this issue, and should be added to a fresh issue as a separate feature request.
It's not clear what patch is up for review/committal here any more, so this can't really be put forward as RTBC. Are we talking about the one at #4 (which was the one set to RTBC) or the subsequent branch at https://git.drupalcode.org/issue/permissions_by_term-3231556/-/commit/42... (which doesn't have an associated MR)?
Sorry - last patch wouldn't apply. Rerolled patch again
Quick re-roll attached - not seeing Console error on 9.5.8
Patch at 42 no longer applies. Still seeing "Uncaught TypeError: once is not a function" error with 9.5.8 vanilla site
Release 2.0 has addressed this problem and dependency is now removed.
Really interesting to hear about the FR and NL groups keeping going through the pandemic, and that there's still enough interest across Europe to warrant national organisations. Felt as though I didn't have much to offer to the conversation yesterday, as we have noticed a steady decline in interest in Drupal within Scotland over the past 5 years, and our organising board (including myself) has completely stalled since the first Covid lockdowns.
Feel a little more inspired now to be a little more proactive. Thank you.
The problem was compounded on my host as it was still set up to run PHP7.4... whereas should be on PHP8.1+. Again cPanel to the rescue.
Great catch with nd_pdo_mysql though. Thanks
Patch attached