thx, merged PR
Call the class Drupal\module\Services or ServiceProvider. Pros: it's very simple, avoids weird naming for more complex module names. Cons: it's still magic naming -- however checking for the all lower case version as well is not too hard to avoid FS problem.
That makes finding a specific one hard to find, even the few test classes that have the same name it's hard to be sure you're in the right one or find it.
I generally navigate to a file using ctrl + E then type it, if there are more than a couple of files with the same name it becomes painful to pick them out.
moduleServiceProvider is magic naming, but at least it helps you find it and the file name tells you which module it's for if you're comparing two service providers.
Adding Reroll patch for 4.3.x
I dont seem to be able to push to push to issue fork.
nitrocad → created an issue. See original summary → .
This is definitely solved in https://www.drupal.org/project/gemini_provider/issues/3504309 ✨ Add Embedding capabilities Active and is already merged.
Closing this issue.
kevinfunk → opened merge request !1
liam morland → made their first commit to this issue’s fork.
Merged! Thank you @vasike!
the_g_bomb → credited rkoller → .
the_g_bomb → created an issue. See original summary → .
I created an issue and mr in wxt_bootstrap for this
https://www.drupal.org/project/wxt_bootstrap/issues/3506314
🐛
Footnotes are busted
Active
The 10.3 patch works to fix the issue with multiple views on a page but we have the issue where exposed filters in media library views break when adding blocks with Layout Builder because there is no ajax applied to them. I have created an MR and attached a patch to use the original form IDs for media library views. We're using Gin LB.
vargenty → opened merge request !11202
All tests are now passing except cspell and eslint.
kevinfunk → created an issue.
Feedback appears to be addressed.
Thanks!
Ahh - I like admin config! Thank you for pointing out the user entity; that's a great example.
Your idea makes the settings form approach make more sense. I was actually already working on that conversion and removing the duplicate menu item from the yml under admin/content. How about I push my initial changes in a few and you can take look at what you think?
-
rajab natshah →
committed 39c75c16 on 10.0.x
Issue #3502527: Change default installation config form for Varbase AI...
-
rajab natshah →
committed 3386bb63 on 10.0.x
Issue #3502527: Change default installation config form for Varbase AI...
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
-
rajab natshah →
committed 248fec60 on 3.0.x
Issue #3506504: Remove Content Planner from Toolbar to prevent conflicts
Hi @murz,
Your changes are good and working fine but we also need to do the same thing in importFieldValue
function in order to import content smoothly, so I've made the necessary changes, pls check.
Thanks,
Arun
-
rajab natshah →
committed b85e6b0c on 3.1.x
Issue #3506504: Remove Content Planner from Toolbar to prevent conflicts
I am not in favor of splitting "section" and "template" into 2 bundles, the current structure is OK.
One of the content entity type from core that has no bundle is user. And it's equivalent of index is "admin/config/people/accounts" which is a global user account related settings form. So way more similar like the settings form you propose.
As mentioned in the MR comments, I had to have a route to attach the Field UI routes on. And currently, no better stuff than an empty controller. Maybe with an explanatory text.
So:
1 if you prefer let's move out of structure to go into Config > Content authoring (admin/config/content) as other Layout Builder related modules put their config entries into.
2 if agreed, I make the route change, cleanup the MR
3 I let you convert the empty controller into a settings form (or I can convert it into an empty settings form and give you the hand) because I am not sure what and how you want to save into config.
What do you think about that?
rajab natshah → created an issue.
@alok_singh, thanks for this, please note, Drupal code standard is two space indents. Your MR has tabs. The change to tabs makes a lot of noise in the MR and due to the indent approach the MR is harder to read and understand the changes.
The background/context of this issue is a D7 to D10.4 migration.
I got this error message: "Error : Call to undefined function cck_allowed_values_php() dans options_allowed_values() (ligne 89 de /var/www/html/dev10.4/web/core/modules/options/options.module)." when trying to run /admin/config/system/cron under Drupal 10.4.2 / PHP 8.2.13 / MariaDB 10.6.18-MariaDB-0ubuntu0.22.04.1.
Applying the patch from comment #2 🐛 Call to undefined function .... in options_allowed_values() Needs work solved the problem.
More details :
Location : https://dev10.4.local/en/admin/config/system/cron
Referrer : https://dev10.4.local/en/admin/config/system/cron
Here is the backtraces for experts :
#0 /var/www/html/dev10.4/web/core/modules/options/src/Plugin/Field/FieldType/ListItemBase.php(65): options_allowed_values()
#1 /var/www/html/dev10.4/web/core/modules/options/src/Plugin/Field/FieldType/ListItemBase.php(48): Drupal\options\Plugin\Field\FieldType\ListItemBase->getSettableOptions()
#2 /var/www/html/dev10.4/web/core/modules/options/src/Plugin/Field/FieldFormatter/OptionsDefaultFormatter.php(38): Drupal\options\Plugin\Field\FieldType\ListItemBase->getPossibleOptions()
#3 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Field/FormatterBase.php(91): Drupal\options\Plugin\Field\FieldFormatter\OptionsDefaultFormatter->viewElements()
#4 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Entity/Entity/EntityViewDisplay.php(268): Drupal\Core\Field\FormatterBase->view()
#5 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Entity/EntityViewBuilder.php(340): Drupal\Core\Entity\Entity\EntityViewDisplay->buildMultiple()
#6 /var/www/html/dev10.4/web/core/modules/node/src/NodeViewBuilder.php(24): Drupal\Core\Entity\EntityViewBuilder->buildComponents()
#7 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Entity/EntityViewBuilder.php(282): Drupal\node\NodeViewBuilder->buildComponents()
#8 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Entity/EntityViewBuilder.php(239): Drupal\Core\Entity\EntityViewBuilder->buildMultiple()
#9 [internal function]: Drupal\Core\Entity\EntityViewBuilder->build()
#10 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(113): call_user_func_array()
#11 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Render/Renderer.php(870): Drupal\Core\Render\Renderer->doTrustedCallback()
#12 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Render/Renderer.php(432): Drupal\Core\Render\Renderer->doCallback()
#13 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#14 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Render/Renderer.php(165): Drupal\Core\Render\Renderer->render()
#15 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}()
#16 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Render/Renderer.php(164): Drupal\Core\Render\Renderer->executeInRenderContext()
#17 /var/www/html/dev10.4/web/core/modules/node/src/Plugin/Search/NodeSearch.php(526): Drupal\Core\Render\Renderer->renderInIsolation()
#18 /var/www/html/dev10.4/web/core/modules/node/src/Plugin/Search/NodeSearch.php(490): Drupal\node\Plugin\Search\NodeSearch->indexNode()
#19 /var/www/html/dev10.4/web/core/modules/search/search.module(80): Drupal\node\Plugin\Search\NodeSearch->updateIndex()
#20 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Cron.php(337): search_cron()
#21 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(395): Drupal\Core\Cron->Drupal\Core\{closure}()
#22 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Cron.php(320): Drupal\Core\Extension\ModuleHandler->invokeAllWith()
#23 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Cron.php(159): Drupal\Core\Cron->invokeCronHandlers()
#24 /var/www/html/dev10.4/web/core/lib/Drupal/Core/ProxyClass/Cron.php(75): Drupal\Core\Cron->run()
#25 /var/www/html/dev10.4/web/core/modules/system/src/Form/CronForm.php(167): Drupal\Core\ProxyClass\Cron->run()
#26 [internal function]: Drupal\system\Form\CronForm->runCron()
#27 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Form/FormSubmitter.php(129): call_user_func_array()
#28 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Form/FormSubmitter.php(67): Drupal\Core\Form\FormSubmitter->executeSubmitHandlers()
#29 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Form/FormBuilder.php(597): Drupal\Core\Form\FormSubmitter->doSubmitForm()
#30 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Form/FormBuilder.php(326): Drupal\Core\Form\FormBuilder->processForm()
#31 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm()
#32 [internal function]: Drupal\Core\Controller\FormController->getContentResult()
#33 /var/www/html/dev10.4/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array()
#34 /var/www/html/dev10.4/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#35 /var/www/html/dev10.4/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext()
#36 /var/www/html/dev10.4/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
#37 /var/www/html/dev10.4/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#38 /var/www/html/dev10.4/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#39 /var/www/html/dev10.4/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle()
#40 /var/www/html/dev10.4/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#41 /var/www/html/dev10.4/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#42 /var/www/html/dev10.4/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle()
#43 /var/www/html/dev10.4/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(116): Drupal\big_pipe\StackMiddleware\ContentLength->handle()
#44 /var/www/html/dev10.4/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(90): Drupal\page_cache\StackMiddleware\PageCache->pass()
#45 /var/www/html/dev10.4/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle()
#46 /var/www/html/dev10.4/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#47 /var/www/html/dev10.4/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#48 /var/www/html/dev10.4/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#49 /var/www/html/dev10.4/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#50 /var/www/html/dev10.4/web/index.php(19): Drupal\Core\DrupalKernel->handle()
#51 {main}
Ok the reason for this is, that the conditionsForm isn't builded entirely correct, it doesn't apply the gathered contexts needed for some conditions.
In our case, it's missing the current user context. Because that context is missing, but it is set as an required context all conditions simply fail, and the JS isn't initialized properly.
Let's adjust the form building to how it is done in https://git.drupalcode.org/project/google_tag/-/blob/2.0.x/src/Form/TagC....
(Don't forget https://git.drupalcode.org/project/google_tag/-/blob/2.0.x/src/Form/TagC... and other potentially crucial code passages).
primsi → opened merge request !2
catapipper → created an issue.
arunsahijpal → opened merge request !143
Automatically closed - issue fixed for 2 weeks with no activity.
Looks like a reasonable change
https://git.drupalcode.org/project/wxt_bootstrap/-/merge_requests/2/diff...
liam morland → made their first commit to this issue’s fork.
It's configured on the activitypub types screen at /admin/config/services/activitypub/activitypub-type.
If you are using the standard note, check which field is assigned to the attachment fields (there's image, video and audio) (e.g. at /admin/config/services/activitypub/activitypub-type/note)
Also think we need to think this one through a little now that I'm looking more closely
'When enabled, the user must confirm the account cancellation via email.'),
While this does set the checkbox to TRUE the person can still uncheck it.
I am going to mark this as RTBC since @larowlan approved the merge request
Reported in 5.3.x but probably also affects 5.4.x and 6.1.x
steven jones → made their first commit to this issue’s fork.
If using view mode is too risky, then yes, helping a website to override the link title easily will be a very nice first step.
Calling/overridding a service, with parameter the section library content entity is passed.
- I approved the BE in #5.
- @hooroomoo did manual testing in #7 and found 2 things.
- @bnjmnm dug into #7 and found it was due to 📌 Exapand Media Library admin theme rendering beyond props form. Active not having been fixed yet. That has now been fixed!
- @jessebaker did a review of the FE code at https://git.drupalcode.org/project/experience_builder/-/merge_requests/6...
wim leers → credited jessebaker → .
-
steven jones →
committed 57546f02 on 8.x-1.x
Issue #3392864 by erom, steven jones: Generate root-relative URLs for...
robertragas → opened merge request !8
Yeah, let's merge it.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
Automatically closed - issue fixed for 2 weeks with no activity.
Yeah, if we're going to allow logging then we should add some sense of what was exported, and to where.
I assume people want this sort of thing so that they can audit people exporting data from the site and keep an eye on them etc.
Looks good, hence moving into RTBC
I encountered this issue too, and the solution suggested in the #2 comment resolved it for me.
mmm Is a file/image field. I'm not sure where it is configured, does the code above indicate it?
robertragas → created an issue.
Thanks.
Can we get a new release, with PHP 8.4 support? Other modules depend on search_api
, so this is holding up PHP 8.4 support in those module too.
Fixing the title of this issue, because presumably we do all the query to be altered, just that there's something about the query metadata that's not quite right.
I 100% agree with #28 in that we should absolutely have a test for this.
I guess we need a module that implements a hook_query_alter
based on some metadata that doesn't get currently passed correctly by the existing code.
Added one line to the gitlab config file
Hmmm, found another problem (revealed by the tests):
- Install Standard (
drush si -y standard
), which supplies content types out of the box - Apply this recipe (
drush recipe ../recipes/drupal_cms_seo_tools
) - Export config (
drush cex -y
) - Inspect the exported config and you'll see that the Page and Article content types don't have any sitemap settings
You won't reproduce this if ECA is already installed before you apply the SEO Tools recipe. That leads me to believe that ECA's event subscribers are not yet registered by the time the model runs.
-
pwolanin →
committed a0a6b767 on 3.x
Issue #3506496: Run 3.x tests on 10,11, and 12
assigned credit
Thanks for that update.
Thanks @danrod!
I am using whatever is provided by the module, not doing any extra compiling.
Drupal core for my development branch is now up to 10.4.2. Production is on 10.3.10. I'd be aligning an update to fluidui with the development branch for the next release, not rushing it through to production before then, so there's no concern from my end about it working with anything older than 10.4.x.
I tried this both ways; with and without a group admin, inviting a new user to the group and site. I get the same failure each time.
Using core 10.4.2, group 3.3.4, Group invite 4.0.0. We also are using Gin Login 2.1.3 and Legal 3.0.3.
User account settings include; allow visitors to create accounts, but administrator approval is required, and email verification is required for visitors to create an account.
Inviting a new user from the group invite, sends the "you have been invited" email. The link opens the account creation screen. When the Create new account is clicked the WSOD message appears.
The email with account details and the one time login is sent. Using this link presents an access denied screen. The user account is never created.
Updated Issue Summary.
The problem occurred on Twig 3.16.0, but no more on Twig 3.19.0
Good to hear that you use this feature!
I cannot recognise the code anymore, since in current dev , a subfield 'status' is introduced.
Please test dev version. I am about to release a new version, so I will wait for yor feedback.
pwolanin → opened merge request !26
Reworked as discussed with @wim.leers, @effulgentsia, @f.mazeikis - the leading slash is not even required so any example file is relative to the SDC itself. If the file exists then the full path to it is given (e.g. for an image src), if the file doesn't exist then it is treated as relative to the root of the site. Added test cases for both these, with and without leading slashes.
smustgrave → created an issue.
Sorry, there was a bug in the first patch.