Merge request in.
On the module main "list" it outputs a drupal warning message if there is an issue that would prevent messages from being logged there. It checks for either the module or the system settings/config. I tested it out with all possible combinations of incorrectly setup and got warnings for all of them, then tried the two ways to get devel mail logger working and the warning messag goes away. Woohoo.
On the sent a test email page, it has a link back to the list of messages you just came from, because assumedly you'd want to see that the test email got logged or not?
...and a return to config link wouldn't be the worst for after you send a test mail.
jnicola → created an issue.
Okay, well that's cool. Since we've got this many interested folks... maybe we can all collaborate?
At the very least I've got some code in here I'd love merged in :) Should be all mergable PR's!
I'm game to co-maintain. It's not as much work as you think.
Let's kick off the official process and go from there. I'll start that here shortly or tomorrow, as work allows :)
Adding in appropriate organization attribution.
Adding in appropriate organization attribution.
I appreciate that others are interested in improving this module. I actually reached out to the maintainer a while back about co-maintainership so I dig that somebody active is interested in taking it further.
That said, this includes work I performed without attribution in Git. Add onto it that the work I did was performed while working for the US Department of Justice who also paid me to perform much of this work... and you really are going to want to make sure the appropriate folks and organizations are getting credit for work performed.
I'd suggest going through the process of this module being recognize as unmaintained and getting maintainership, then merging in my and any others work with proper attribution, and then you can spin off a 2.x with your work or modifications to work performed by myself and/or others.
I'm familiar with it.
Unfortunately, you can't always utilize it. Whether it's the hosting services doesn't recommend it, or you've got uninformed obstinate devops team members who make you want to pull your hair out even though you shave your head...
For those situations, a minimum lifetime is useful :)
Okay, I recognize at this point you've probably moved on, however I was able to figure out the solution, there were some changes to the way config stashed values relating to user roles somewhere in 2.x
I've got the fix out in the 2.0.x dev branch if you want to try this all out!
#11 did not work for me. Specifically because there are other values in my repositories array already, so one without a key didn't fly. Adding different keys like "ckeditor5-anchor-drupal" or "northernco/ckeditor5-anchor-drupal" or "northernco" when run with `composer require northernco/ckeditor5-anchor-drupal` resulted in:
Could not find a matching version of package northernco/ckeditor5-anchor-drupal. Check the package spelling, your version constraint and that the package is available in a stability which matches your minimum-stability (dev).
Can confirm though that the given install directions for step 1 is busted.
Faffing around with this now.
How does one determine exactly which menu they are adjusting the manipulators on?
I am using the code from the patch for 10.2, so perhaps this has been addressed later... but I'm looking to remove checkAccess from certain menus as we can simply rely on published... but I'll be darned if I can't figure out how to determine the menu based on what's available to me in the event.
I'll try and get that out here soon!
Patch doesn't apply to latest dev branch or 3.4.0 release. Doh!
FWIW I had no issues recently requiring this via composer. May not be an issue anymore.
Here's my patch on some initial work.
Cache clear always deletes
Cron checks against state of when 404 was last generated
Standardized some calls to strings and such to keep code DRY
Attached is my not terribly graceful patch that modifies Fast404GeneratorSubscriber::onKernelResponse to instead of writing the HTML content all in one line instead takes the response, saves it to a variable, and does a very ungraceful string replace that takes and rewrites it with and the meta tag prior to it.
Now you can discern fast 404 generated HTML from standard HTML with confidence and test against it. Woo. Hoo.
jnicola → created an issue.
jnicola → created an issue.
Uploading patch with slight tweak after code review. Original code returned based on first item value, so now we just return on the first found media item versus assuming the first item is 0.
Attached a patch that works for us. I recognize the better way to do it is a commit in a fork but... eh I couldn't be bothered and since nobody else seems to be having this problem it likely doesn't matter.
Solution though was simple. Instead of assuming the key of 0 exists, just iterative over keys until you find the first numerical key, and run with that if you get it. Further improvements are likely possible, but this works and doesn't feel hacky to me.
jnicola → created an issue.
So as misfortune would have it... I needed this, and nothing else would do. There's just no way to programmatically expand everything in a menu tree for whatever reason.
This works GREAT. Update script is great, everything works... color me impressed but nice work and it did the trick first try!
This has been up for a LONG time with what seems like little interest by the maintainer. There's also been a ton of improvements to this that have been done now across several projects.
Maybe it would be worth breaking out into it's own contributed module at this point?
Tested, works. There's not even any code changes it's just adjusting what version of drupal is supported in the info.yml file.
Fair fair, well, let's see what comes in as more folks run into this and troubleshoot it, and thanks for everyones time!
Ah yep, Kint was indeed my issue. Disabling it has allowed me to proceed.
I do think it's worth noting and continuing to discuss here that some change between 11.0 and 11.1 is causing this issues for a bunch of contrib modules and breaking site upgrades for folks. It's also not terribly easy to troubleshoot with the current error output, even with backtrace. What changed in core that resulted in this sort of sensitivity across a variety of modules? Can anything be done to address this better and/or useful error output to inform module developers of their issue?
So I searched for \Drupal::config() inside all of modules and themes, found nothing. I'll see about xdebug for additional backtrace.
I'm seeing similar issues pop up accross a multitude of other modules like this:
https://www.drupal.org/project/launch_checklist/issues/3498288#comment-1...
🐛
"$container is not initialized yet" errors following upgrade to D11.1.0
Active
In that case the issue stemmed from:
include \Drupal::service('extension.list.module')->getPath('launch_checklist') . '/inc/routes.inc';
Granted, I am not using that particular module, but am seeing these issues out there.
Out of curiosity, how were you able to track the issue down to this particular module?
I'm having a similar issue with a Drupal 11.2 update from 11.0. No stack trace showing me any modules or anything in particular. Curious what methods you used that I can perhaps use for my issue.
hestenet → credited jnicola → .
Marking as reviewed and tested by the community. Enough folks have weighed in on this one, it's good to go and improves the module.
Same issue for us at USDOJ:
Call to undefined method Drupal\Core\Field\BaseFieldDefinition::createDuplicate() in Drupal\content_type_clone\Form\CloneContentType::cloneContentTypeField() (line 67 of modules/contrib/content_type_clone/src/Form/CloneContentType.php).
This MR fixed the issue, though there was a drupal message stating:
"The field moderation_state cannot be cloned because the createDuplicate method does not exist."
Perhaps expected, and everything worked for the most part so.. good to go?
You know that the Google charts API this uses is defunct and this module is consequently abandoned?
Okay, figured out the double menu items was being caused by something else. I'd still love a code example of how to programatically set the values on a menu item though as I'm having some inconsistent results locally. Ah well.
Man would this be useful right about now... i'd even accept something at returns an array of plugins as I could reliably just grab the first!
Just ran into this in 10.3.x with views on the USDOJ website where the pager would sometimes not render without a discernable rhyme or reason. Sure enough, adjusting the pager ID to 99 ensured that there weren't issues.
I don't have steps to reproduce from scratch, nor the liberty of time to faff around with reproducing this, but the pager ID collision does appear to be something that can still happen.
Stands to reason you could perhaps write a test for this that has a view rendering content, some of which has a pager on it, and both using the same pager ID of 0, but the view in the content pager is empty, which in turn bubbles up to the overall view pager ID.
I wish there were an easy solution such as setting pager ID to the views limit + 1, but if the overal view is 25, and the view in the content displaying in the view is limited to 25, you'd have the same pager ID collision again.
Why does pager ID need to be numeric anyways? If it could be alphanumeric you could go view-name_dislay-name?
I'll try and find some time to look into this next week. It's a big Holiday here and I'm about to be out through next Monday!
Okay, NEVERMIND! Got it all working, not sure where that error came from, but it works good.
Definitely needs some documentation upgrades but overall this actually seems pretty robust and functional!
jnicola → created an issue.
No, 2.x should be good to go on this project. Could you elaborate on steps and what failed for you?
I'll try and find some time today or tomorrow to spin up a site from scratch and update the directions if necessary.
Huh well would you look at that, we don't have it in there!
https://git.drupalcode.org/project/simple_grouped_content/-/blob/1.2.x/c...
I'll have to look up how to suggest it. I think this should all be compatible with 9 and 10.
We've not tested this with 11.
Drupal 10.3
Are you using composer? Should be in the requirements there.
Double check that the save button is there and that it actually saves. Our problem is that we can get the Save button back using a related patch for Gin, but unfortunately the submission does not succeed with no ajax error nor drupal log error.
Oh and sorry composer errors. Annoying that this isn't seen as a drupal package for some reason. Perhaps it's because it started as a sandbox. I added back in the repositories code. Try it out again with the respositires code added in your composer.json.
It's not built for group 3.x yet, just 2.x and 1.x if you want to go that far back.
While group 3.x is recommended, a lot of downstream modules aren't fully sorted yet that this depends on, and the place I work at that gives me a very modest amount of time to work on this just barely got on 2.x, it'll be a while before i can retool this for 3.x.
That said, this has been working with us for 1.x and now 2.x for 4 years. It's a pretty stable foundation to build upon :)
So I've updated the landing page information and the versions, as we've had a few updates come out since. It's good to go, try it out and let me know if it works for you!
Hey there and thanks for trying this out!
You'll need to download / require Drupal with composer, and then require this as well. This will download all the other requirements. Then, as part of the Drupal Install you'll be prompted to pick an install profile, and this will be listed. Select this install profile, and it should work!
Let me know how that goes for you. I'll update the documentation this morning.
Ugh, go figure I spent all spring making the switch to 2.x for one of our two big products, and now 3.x is ready!!!
Folks are welcome to do so, if the problem even exists there.
We're on the life support 1.x stuff until we migrate to group 2.x
Okay got a merge request for it for anyone who may want this.
https://git.drupalcode.org/project/group_content_menu/-/merge_requests/43
Didn't investigate tests for this, but could reasonably write one I'm sure.
jnicola → changed the visibility of the branch 3487080-nodeformalter.php-issue-when to hidden.
jnicola → created an issue.
This is not fixed for us with latest in 3.x dev branch.
Linked tickets also seem to be closed for duplicate, or the one core issue just trails off with folks pointing to this project (gin).
What is the actual solution for folks using 3.x? Given how many people have come back here and mentioned it is still not working this does not seem to be marked appropriately as fixed.
We've got this issue. Been faffing with the code above, doesn't seem to work. Also doesn't really capture folks using gin as a base theme? Also just not sure about that first conditional of if the theme IS NOT gin? Without comments or a link to another issue I'm guessing at exactly what it's trying to resolve.
Here's our modified version that checks if it is GIN or a GIN sub theme, but for us isn't working. Even skipping the initial theme check (where you went != and I went == or in array) it does not seem to resolve the issue.
// ATTEMPT TO FIX GIN LB OVERRIDE ENTITY FORM MISSING SUBMIT BUTTON!
$theme = \Drupal::theme()->getActiveTheme()->getName();
$base_themes = array_keys(\Drupal::theme()->getActiveTheme()->getBaseThemeExtensions());
if (
$theme == 'gin'
|| in_array('gin', $base_themes)
) {
// Enable gin_lb theming for custom frontend! forms too.
$gin_lb_form_ids = [
'override_entity_form',
];
if (in_array($form_id, $gin_lb_form_ids)) {
$form['#after_build'][] = [
'Drupal\gin_lb\HookHandler\FormAlter',
'afterBuildAttachGinLbForm',
];
$form['#gin_lb_form'] = TRUE;
$form['#attributes']['class'][] = 'glb-form';
unset($form["revision_information"]);
unset($form["revision_log_message"]);
unset($form["revision"]);
unset($form["revision_log"]);
}
}If you're placing a block inside another block you'll want to pull all cache tags from the first block into the second.
Sounds like it worked for you though!
Ah, I am not seeing them for some reason. I'll go look again and see what I can address from them, thanks for your time as always!
Well, a few things to that end.
Yes, Project Browser is the way folks will likely find recipes. That said, as with most things in Drupal, the "next big thing" historically comes and goes, but it's the base concept that remains. That's the beauty of it all being so extensible, and has allowed Drupal to have reinvented many aspect of module management, config management, content creation, layout management. From panels, to beans, to features... can we say someone won't come along with something better than Project Browser in the future? I don't think staying true to Drupal's history we can.
Respecting the desire though to give Project Browser it's fair shake, while also recognizing extensibility is the ladder that got us all on this roof... I kept RecipeDiscovery built in such a way that while it heavily favors the two directories you suggest we try and focus RecipeDiscovery down to... it can be used to discover recipes in other locations.
So if install profiles ever make a comeback and ship with Recipes, or hey maybe the next big "starshot" will have it's own directory... whatever the next big thing is, this can accomadate for it, but favors core, just like ModuleDiscovery.
Ultimately, I think this threads the needle of being as true to the original ModuleDiscovery object as possible, while navigating the current desired direction of Drupal.
As for needing more work, could you please be specific so as this can meaningfully stay moving? Just saying "Do better, see this" leaves this perpetually in limbo. Plus, I did review your project browser and did borrow from some of it.
One simple idea how to test: You could write a custom controller that calls RecipeDiscovery and gets all of the recipes from core and outputs them in a nice list, or a table, or whatever makes you happy! If it finds all of the recipes as expected, that's good! If you want to see actual output, do a list output of each recipe returned to you!
You can also test this works by attempting to load the test recipes. where it will load all but one that shouldn't load because it throws an exception.
Would love it if some more folks got interested. I'm still flummoxed that a standardized way for folks to discover Recipes is an uphill battle with outright disinterest. It's open source, give people the tools and let it grow!
Eh, I suppose. I wonder just how much of Drupal would need to be redocumented or fixed once return types are specified and discover how much wasn't actually as expected...
Is there any loss to be had adding a sanity check here besides a milisecond or two of time?
@walkingdexter could you explain your resistance or what the issue would be in implementing this bit of code?
I don't think it's fair to say that getOperation() returning NULL is a third party problem, since getOperation does not specify return types.
We were able to fix this by adding ".text-formatted" selector to the accordion JS selectors, restricting this functionality in theory to just the WYSIWYG content. It worked for us, but we can't guarantee the selector will apply to your situation, and may not warrant a PR since the class can't for sure be relied on.
I fail to see why problems in 3.x and 2.x need to stop a solution from making it to 1.x.
Have you even determined the problem exists there?
This fixes the same error for me that I experience when deleting group_content_menu items.
I don't think it would be criminal to consider making the code here a bit more tolerant, especially since in it's tolerance everything is hunky dory.
Opened MR, and passes. Ready for review!
Got a working patch, attached.
jnicola → created an issue.
jnicola → changed the visibility of the branch 3446354-expand-discovery-class to hidden.
This has been updated and now has tests that check the RecipeDiscovery class works as expected.
Wouldn't mind some additional review from folks.
Ah okay, got it!
I've got time at work and am going to try and get some tests for the updated recipe discovery class in the MR and then see about getting this out.
We're getting the same error, and I can't see the difference for the fork you've opened here?
Escalating to critical since you can't use this at all nor edit anything else while it's enabled.
Alrighty, looks like this patch fixes things for us in 2.2
Specifically, the service changed, and then $group_relationship->getEntityTypeId() no longer returns the referenced entity type ('node' for example) it now just returns that it is a Group Relationship. Booo.
Chucking this in a note here for myself and others, the latest patch doesn't work with 2.x as path.alias_manager has changed to path_alias.manager (see the _ and . moved).
Getting this error as well as part of a Drupal 2.x upgrade.
No steps to reproduce, it would be unreasonable for us to do so as well given the size and complexity of our site.
Still, there's something amiss here in the upgrade.
jnicola → created an issue.
I see this was reopened ... are we doing this or not?
Ah yep, this was due to actually happen at some point as the API was supposed to go away YEARS ago!
Unless there's something new for Google Charts or equveilant, probably time to consider this as done.
@thejimbirch it's sort of ready!
Since I resolved everything, RecipeDiscovery was moved to RecipeConfigurator (see https://www.drupal.org/project/drupal/issues/3447210 📌 Move RecipeDiscovery into RecipeConfigurator Needs review ) so I had to redo the work on RecipeDiscovery. So I redid the work, added some functionality based on some suggestions from @phenaproxima and had pinged them for a code review. I'd love for you to take a gander at it as well!
I also need to add tests. Writing those would be the goal early this week, but I am having trouble getting DDev to run phpunit tests. I couldn't even get ddev to spin up Drupal 11 without some notable deviation from the main Ddev directions, so I'm sure the problem lies somewhere in thee.
If anyone reading this has availability to pair through writing Phpunit tests with me, I'd be forever grateful!
thejimbirch → credited jnicola → .
Looks good to me! Could you elaborate on some ways to test?
@jimburch I think this is actually on hold and may not even happen at all unfortunately.
The main push apparently is for this all to exist in project browser. No idea how far out that getting brought into core is.
I also opened a ticket for the new DiscoveryClass, which I included in here but has changed some, etc etc.
https://www.drupal.org/project/drupal/issues/3446354
✨
Expand Drupal\Core\Recipe\RecipeDiscovery to allow discovering available recipes, likely for use in Project Browser
Active
Recipe discover also needs a bit of time since we need to move validation from Recipe creation to it's own stand alone method.
https://www.drupal.org/project/drupal/issues/3446329
📌
Recipes' ConfigConfigurator should not immediately check for conflicts with active config
Active