arcaic → created an issue.
Applies to Site Guardian 1.0.5 on Drupal 10.2.5 and seems to work fine.
Not sure what's causing this. We have it installed on a multi site system and on one of the sites we were getting this message when trying to enable css/js aggregation.
Even after uninstalling the module we still had the issue.
An export and search of the sites config found the following entries in the system.performance.yml file.
minifyhtml:
minify_html: 0
I did a single file export of system.performance.yml, removed the minify_html settings from the file and did an single file import and was able to enable css/js aggregation.
I think that's much clearer. Many thanks.
I've only tested on one site so far but the s3fs_assets → module seems to resolve the issue so far and allows us to have the aggregated css and JS files on S3 again.
Thanks
This is not a duplicate.
The other task muddies the issue considerably for those of us who are not well versed in "stateless infrastructure" or Kubernetes and then talks about setting up persistent volumes with shared EFS for each Pod.
The other thread is about how to handle the core change within S3FS. This one is about explicitly and as simply as possible explaining to users of the module who may not be as well versed in all this as yourself what the situation is.
We need a clear statement of what this change means (maybe on the module page) for S3 because for me at least the module used to work fine without going through too many hoops and now it doesn't because of the core change.
I am no closer now to knowing if there is a way I can get it to work or if I am wasting my time.
As far as I can tell this is not an issue with the module but your concern is with the way core manages blocks and revisions.
As far as this module is concerned, as is the case for core, if a revision of an entity still references a block then the block is not orphaned.
Closing.
If you feel I have misunderstood then feel free to open another ticket with a more detailed explanation of what is wrong with this module and ideally some recommendation on how it could be modified to address any issue.
@praveen
Thanks for reporting the bug.
I have updated dev branch with a fix so should be ok now.
I didn't use your patch as I think it's more sensible to not alter the requirements/status if the benchmarks have not been run yet and only return results when the timestamp has been set (which happens when the benchmarks are run).
If you can check it works ok for you then that would be great.
Uninstall and re-install the module, then visit the status report without having run the Server benchmarks.
This ensures there is no config when the status report is run and before the fix would trigger the issue.
Many thanks
Andy
Not clear what you mean here.
If you remove a block from a nodes layout and the content type has revisions enabled then when the layout is saved a new revision of the node will be created.
The new revision will not reference the block but the previous revision will still reference the block so it is not orphaned.
Only if you delete the node will you "potentially" see an orphaned block but in my experience this is rare now as the layout code seems pretty much ok and doesn't orphan blocks anymore.
Even when you delete nodes completely you will see entries remaining in the inline_block_usage table with null values for the entity_type and entity. These get cleaned up when cron runs.
When this module was first created it seemed quite easy to have layout blocks be orphaned and of course if you are doing your own thing in code you can mess things up quite easily.
Hope that helps let me know if not.
Just adding a me too here so not much real help.
All our sites that use the Legacy Classic Toolbar (3 or 4) are seeing this issue.
Haven't been able to see whats wrong but for now we have switched to using the Horizontal Modern Toolbar and enabling "Show Secondary Toolbar in Frontend".
Andy
I don't think there is any way I am going to be able to prove how it exhibits the behaviour.
Its on a complex site thats been running for a few years just being upgraded to D10 and I think the chances of reproducing it in a minimal install are pretty much zero.
I made the patch so we could get our site running and so if anyone ever gets the issue they would have a possible solution.
The BUG is in the display of the geofield_map widget. It is a BUG whether you can reproduce it or not but I fully understand you have nothing to go on. TBH I suggest you close as "cannot reproduce" and at least its there for reference should anyone else encounter it.
Patch against 3.0.x
I had a very similar issue to this in that when running db updates on a D10 upgrade I was getting this error reported from rabbit_hole_update_8106 when doing drush updb.
-- Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "node_type" plugin does not exist. Valid plugin IDs for Drupal\Core\Condition\ConditionManager are: current_theme, request_path, user_role, entity_bundle:block_content, entity_bundle:comment, entity_bundle:contact_message, entity_bundle:media, entity_bundle:menu_link_content, entity_bundle:node, entity_bundle:redirect, entity_bundle:shortcut, entity_bundle:taxonomy_term, entity_bundle:paragraph" --
What I found is that it seems to be something to do with pathauto_update_8108. This update is titled "Update node type conditions from node_type to entity_bundle."
I found that if I reset the pathauto updates to 8107 before the upgrade and run updb then, when I run drush updb again after updating the code base to D10 the rabbit hole update processed without issues.
To reset the pathauto updates to 8107 use the following...
drush eval "drupal_set_installed_schema_version('pathauto', '8107');"
Note: This drush command will only work on D9.
Looking at the PA 8108 update it seems safe to run any number of times as it only fixes pathauto patterns that have the incorrect type and selection criteria.
Not entirely sure whats going on but I guess that pa8108 got run as part of an update at some point but then normal CMS actions have created further changes that 8108 fixes but as its already run it doesn't get the chance. What the root cause is I don't know.
Adding patch for 4.0.0
Fixes for above issues.
Fixed WSOD on config page.
FIxed WSOD on endpoint page - Created new controller for endpoint page and removed from existing controller.
Corrected use of logger to latest best practice. Created logger channel service and injected as required.
Get endpoints from database instead of parsing routing file.
Flood control for an IP address will be reset if a call is made with correct key.
I have fixed the coding standards issues and taken onboard the security recommendations.
By its nature this module is useful only for developers so rather than alter/add to the permissions needed to allow it to work I have made the following changes..
- Made the modules description more explicit as to its function.
- Moved it into the 'development' package.
- Added restrict access to the permission it creates.
- Added a warning the permission that informs the user of what it does and the implications of giving it to a user.
New release, now beta7.
I couldn't get the patch in #2 to apply. It would patch the view module info yml ok but fail on the main modules info.yml.
I tried to recreate it and my patch was exactly the same as kalpaitchs. V weird.
I've created my own version that closes the bracket on the modules description and adds a package entry in the YML. This applies ok for me.
I suggest that if anyone has trouble with one or the other then try the other.