Account created on 16 May 2017, about 8 years ago
#

Merge Requests

Recent comments

When I apply this patch on a fresh D11 install via DrupalPod and try to use the filters summary in the Header of the Content view, an Ajax error is thrown and the Header remains unchanged.

If I switch back to version 3.2.0, there is no Ajax error and the summary renders as expected.

I get this when trying to enable the dev version of the module with this patch applied:

The service "sites_simple_sitemap.service" has a dependency on a non-existent service "plugin.manager.site". Did you mean one of these: "plugin.manager.block", "plugin.manager.archiver", "plugin.manager.action", "plugin.manager.mail", "plugin.manager.sdc", "plugin.manager.editor", "plugin.manager.filter", "plugin.manager.search"?

The module successfully installs despite the error, but the error prevents any drush commands from completing.

I get the same result when trying to patch the alpha version.

I am able to apply the patch, but I am unable to then upgrade to D11, probably because one of this module's dependencies is also not D11 compatible.

I was able to apply this patch while on D10, but I was then not able to upgrade to D11 because even though the info.yml was updated with the D11 version constraint, the composer.lock still showed

"require": {
    "drupal/core": "^8 || ^9 || ^10"
},

even after deleting and regenerating the lock file and clearing composer caches.

This patch works to make the module installable on D11, but when I go to /user, I get this error:

TypeError: Drupal\advagg\Asset\CssOptimizer::__construct(): Argument #2 ($event_dispatcher) must be of type Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher, Symfony\Component\EventDispatcher\EventDispatcher given, called in /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 in Drupal\advagg\Asset\CssOptimizer->__construct() (line 17 of /var/www/html/repos/advagg/src/Asset/CssOptimizer.php).

This theme has a dependency on "gesso_helper," which is a helper module of the "gesso" project, which is not compatible with D11 and does not have an issue open for D11 compatibility, so while it is possible to apply this patch, composer stops the user from updating from D10 to D11 because of the incompatibility.

@introfini I see the new option to "Use parent entity for comment tokens," but I am not able to mention another user. Both users have enabled comment notifications. I don't see any text format filter active.

Confirming the added functionality. With Linkit enabled and the new "Remove links to unpublished/non-existing entities" checkbox checked in the text format, a user is able to add a link to an unpublished node, and the link shows up as a link in the WYSIWYG to an admin, but the link is rendered as a span to users that don't have permissions to view unpublished content. Likewise, the link for a node that is linked to and subsequently deleted becomes a span after deletion.

Can confirm the improved distinction between actions dropdown and the area that it floats over:

I was able to apply the patch cleanly. After enabling/configuring the Content Lock module, I can confirm "Break lock" appears in the Actions dropdown in the content list.

Confirming the fix as described in the comment above. Applied the patch, deleted the Article content type on a fresh D10.5.1 installation. No errors.

Confirming that this patch can be applied to allow installation of the module on D11.

Confirming the provided patch allows for module installation on D11.

I was not able to apply this patch to either the 1.0.1 or the dev version.

I can confirm the patch in #4 can be applied and allows the installation of the module on D11.

However, I was presented with this error on the login page:

Deprecated function: explode(): Passing null to parameter #2 ($string) of type string is deprecated in nofollow_noindex_page_attachments() (line 22 of /var/www/html/repos/nofollow_noindex/nofollow_noindex.module).

This did not stop the site from working; I was able to edit and save the module configuration without issue and the error then did not appear again.

Confirming this patch cleanly applies to the 2.0.x version of the module and allows the module to be installed on D11.

TL;DR I could not reproduce the issue.

I spun up a clean D10.5.2 install on a DrupalPod instance. I followed the instructions on the project page to add the base_url replacement token to the output of a link. The expected result is rendered (/home) in the view preview.

I then enabled Language and Content Translation and added French as a language. I viewed the same view, this time using /fr/ in the URL. The expected result is rendered (/fr/home) in the view preview.

I could not get this patch to apply on a DrupalPod instance generated from this issue.

I was able to replicate the error on a clean install of D11.2.3, but I could not get the patch to apply.

Confirmed that the patch/MR works on a vanilla install running D10.5.2. New permissions are available and views by Anonymous users are no longer logged to the block after leaving "Anonymous" user permission unchecked.

I was not able to test if the patch makes the module installable on D11 because I got this error:

TypeError: Drupal\user_visits\EventSubscriber\UserVisitsSubscriber::__construct(): Argument #5 ($request_stack) must be of type Drupal\Core\Http\RequestStack, Symfony\Component\HttpFoundation\RequestStack given, called in /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 261 in Drupal\user_visits\EventSubscriber\UserVisitsSubscriber->__construct() (line 69 of /var/www/html/repos/user_visits/src/EventSubscriber/UserVisitsSubscriber.php).

Yes, I can confirm I was able to follow the README instructions without issue.

This patch does indeed add the option to choose <p> as the tag that will be wrapped around the chosen field

But it does not seem to render the chosen tag.

In fact, no matter what I chose, it would always render as an h1. Perhaps I'm missing something?

Can confirm the patch allows the module to be installed on D11. Cannot speak to the other enhancements.

Confirming submit button is now wrapped with "actions" wrapper and styling is consistent with other buttons.

bhogue made their first commit to this issue’s fork.

I can confirm that I was able to preview/create the view as per the instructions above without any crash/console error.

However, when I went to the page that my view was configured to display on, this error was displayed:

Debug: Calling Drupal\Core\Render\Renderer::render with NULL is deprecated in drupal:11.3.0 and is removed from drupal:12.0.0. Either pass an array or skip the call. See https://www.drupal.org/node/3534020. in Drupal\Core\Render\Renderer->render() (line 215 of core/lib/Drupal/Core/Render/Renderer.php).
Drupal\Core\Render\Renderer->render() (Line: 54)
Drupal\html_title\Plugin\views\field\NodeHtmlTitle->renderText() (Line: 1260)
Drupal\views\Plugin\views\field\FieldPluginBase->advancedRender() (Line: 230)
template_preprocess_views_view_field()
call_user_func_array() (Line: 302)
Drupal\Core\Theme\ThemeManager->Drupal\Core\Theme\{closure}() (Line: 326)
Drupal\Core\Theme\ThemeManager->render() (Line: 499)
Drupal\Core\Render\Renderer->doRender() (Line: 229)
Drupal\Core\Render\Renderer->render() (Line: 1811)
Drupal\views\Plugin\views\field\FieldPluginBase->theme() (Line: 778)
Drupal\views\Plugin\views\style\StylePluginBase->elementPreRenderRow()
call_user_func_array() (Line: 107)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 908)
Drupal\Core\Render\Renderer->doCallback() (Line: 440)
Drupal\Core\Render\Renderer->doRender() (Line: 229)
Drupal\Core\Render\Renderer->render() (Line: 715)
Drupal\views\Plugin\views\style\StylePluginBase->renderFields() (Line: 579)
Drupal\views\Plugin\views\style\StylePluginBase->renderGrouping() (Line: 467)
Drupal\views\Plugin\views\style\StylePluginBase->render() (Line: 2213)
Drupal\views\Plugin\views\display\DisplayPluginBase->render() (Line: 1595)
Drupal\views\ViewExecutable->render() (Line: 201)
Drupal\views\Plugin\views\display\Page->execute() (Line: 1692)
Drupal\views\ViewExecutable->executeDisplay() (Line: 80)
Drupal\views\Element\View::preRenderViewElement()
call_user_func_array() (Line: 107)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 908)
Drupal\Core\Render\Renderer->doCallback() (Line: 440)
Drupal\Core\Render\Renderer->doRender() (Line: 229)
Drupal\Core\Render\Renderer->render() (Line: 242)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 633)
Drupal\Core\Render\Renderer::Drupal\Core\Render\{closure}()
Fiber->start() (Line: 634)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 235)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare() (Line: 131)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 188)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 53)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 715)
Drupal\Core\DrupalKernel->handle() (Line: 19)

I also was not able to apply the "allowed_options.2.0.0.rector.patch" patch, but I WAS able to apply the "allowed_options_d11_version_fix_3428840_4.patch.patch" to install the module on D11.

I can confirm that this new permission works as intended.

I could not reproduce the error, but I also don't see any error or unexpected behavior with the patch applied.

Can confirm module functionality is maintained.

Sorry, yes, nevermind, that display behavior is consistent with other items that appear in that space at that screen width (User, Shortcuts, etc)

Tested on a DrupalPod instance running D11.3-dev with Gin 5.0.3. Can confirm that Coffee displays in the top bar and functions as expected.

Tested on a DrupalPod instance running D11.3-dev with Gin 5.0.3. Tour appears consistently in #toolbar-administration-secondary in all cases.

But the text of the button ("No tour"/"Tour") disappears at certain screen widths. It is not visible until < 576px, then again from 976px - 1279px. The question mark portion of the button stays visible at all widths.

I can confirm that after applying the patch, the dependency is noted on the "extend" page and when installing the module, the modules it depends upon are also installed.

Confirming requested/added functionality is maintained with inclusion of newest changes.

When I install the theme in a DrupalPod instance running D10.3 and with this patch applied and then view the homepage, I get this error:

Drupal\Core\Render\Component\Exception\InvalidComponentException: [items[1].text] Object value found, but a string is required in Drupal\Core\Theme\Component\ComponentValidator->validateProps() (line 203 of core/lib/Drupal/Core/Theme/Component/ComponentValidator.php).

and when I run phpcs I get this:

phpcs --standard=Drupal,DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml,twig web/themes/contrib/prototype

FILE: /var/www/html/repos/prototype/components/02-components/page-title/page-title.css
--------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------------
 1 | ERROR | [x] Additional whitespace found at start of file
--------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------------


FILE: /var/www/html/repos/prototype/components/05-pages/basic/basic.css
-----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
-----------------------------------------------------------------------
 1 | ERROR | [x] Additional whitespace found at start of file
-----------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
-----------------------------------------------------------------------


FILE: /var/www/html/repos/prototype/prototype.theme
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
--------------------------------------------------------------------------------
 211 | WARNING | Hook implementations should not duplicate @param documentation
--------------------------------------------------------------------------------

I can confirm the patch adds the requested permissions and those permissions can be set/unset without error.

I can confirm that I can edit content and detach the editor into its own window, and when I close that window, the sidebar version of the editor does not reopen, but I also cannot edit the content again without reloading the page (see the attached video).

I can confirm that I get no output when running the above command (on a DrupalPod instance running D10.3.14).

Can confirm this works as advertised. Modified devel Toolbar settings, cleared caches, those same menu items appear in Tools menu under "Development."

I was not able to reproduce the error. I tested on a DrupalPod environment running D10.5.1 with the 3.x-dev version of the module and version 5.4.0 of devel_generate.

Confirming that patch fixes issue introduced by change in CKE icon handling.

Confirming patch works as advertised.

  • Add SEO status field to Article content type
  • Verify field displays as not collapsed when on Article node form
  • Update field's form display, checking box "Show widget collapsed by default"
  • Go back to Article node form and verify field displays collapsed

I am not able to replicate this. I used a DrupalPod instance with D10.5.1 and module v2.0.0. Followed the steps above; error did not occur when deleting child term (with "delete children" unchecked OR checked), nor would it occur when deleting a parent term (with "delete children" unchecked OR checked).

This error shows up after upgrading to Drupal 11

The module does not yet officially support use on D11. You may want to try applying the patch here first:
https://www.drupal.org/project/we_megamenu/issues/3435602 📌 Automated Drupal 11 compatibility fixes for we_megamenu Needs review

Can confirm.

I replicated issue on a DrupalPod environment, getting the same error as above when entering an invalid Drupal.org username using the field provided by the module.

After applying the patch and again supplying an invalid Drupal.org username, an error message appears on the form and the field is highlighted as an error.

Can confirm it works as advertised. This was my testing process:

  • Apply patch
  • Enable Webform UI
  • Add "Birth Date" date field to contact form
  • Scroll down to "Form Display" section, see Autocomplete option defaulted to "On"
  • Save form
  • View form
  • Begin typing name in Name field, use autocomplete to fill out the field
  • Verify that Email and Birth Date fields are also autocompleted

Confirmed the patch in #20 seems to fix the issue. Tested module v3.1.0 on D10.3.14. Styles persist with CSS aggregation on.

Tried to review/test this but I don't have a AcquiaDAM account so I can't complete the config.

Can confirm theme works without error on D11.

I get this error when running the module with this patch on D11

Fatal error: Declaration of Drupal\spa\Plugin\Block\SpaBlock::submitConfigurationForm(array &$form, Drupal\Core\Form\FormStateInterface $form_state) must be compatible with Drupal\Core\Block\BlockBase::submitConfigurationForm(array &$form, Drupal\Core\Form\FormStateInterface $form_state): void in /var/www/html/repos/spa/src/Plugin/Block/SpaBlock.php on line 124

I do not get that error when running the patch with D10

I have verified that the most recent changes work on D11.

Would be great if this list could include a quick indicator of what the module use is (integration/chatbot/content generation/site building/etc).

Yeah, same here. If the process has changed, it might be worth updating the module instructions to be more useful beyond "Create an account following the simple steps on the website."

Trying to determine if this is something I can work on ... what is "sandboxes" changing to? Or is it changing from something else to "sandboxes?" I know the other issue mentioned "stage," but I'd like to be certain before doing anything.

But Geolocation still has the stated dependencies, yes? You're just saying I should take it up with them (core)?

Applying this patch causes this issue:

Fatal error: Type of Drupal\inactive_autologout\Form\SettingsForm::$typedConfigManager must not be defined (as in class Drupal\Core\Form\ConfigFormBase) in /var/www/html/web/modules/contrib/inactive_autologout/src/Form/SettingsForm.php on line 15

I figured out in my case that a custom module was causing this error

Drupal\Core\Field\FieldException: Attempt to create a base field bundle override of ... without an entity_type in Drupal\Core\Field\Entity\BaseFieldOverride->__construct() (line 107 of /var/www/html/web/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php).

I had to add this line to the offending custom code

->setTargetEntityTypeId($entity_type->id())

This error did not come up until I clicked the "Reanalyze content for links" button at the very bottom of linkchecker's config page.

Yes, I'm having the same issue. I have it working on one site, but on another — with the same configuration options aside from which fields on which content types it's checking — the "Progress of link extraction" doesn't move no matter how many times I run cron. The list doesn't show any Status Code and every item's Fail Count is 0 and Last Checked is "Never." This is on a pre-production environment, but I can't imagine that should matter.

Just another +1 here for all the same reasons everyone has already stated.

This seems to work for me, but I'm not entirely sure what you're after and this is my first exposure at Experience Builder.

This is what I added to the CSS

.example-flexbox-break > [data-xb-component-id="slot"] {
  flex: auto;
}

Looking into this at NEDCamp. Adding the issue tag.

I've reviewed the changes and can confirm all instances of "staging area" have been replaced. It could always be futzed with more, but this seems like it's been thoroughly de-jargonized.

Sorry, @anybody, I don't have the expertise to provide a fix for this particular issue.

I just added a little spacing between the results and the icons when stacked. They looked a little squished.

Thanks for the information. Seems like something the maintainers would want to note for users, not just for transparency but primarily because it's essentially a breaking change.

It's not terribly nice looking, but I can confirm it works. Too bad it didn't do anything to fix the problem I have, but that's another story.

Sorry, I discovered I had to update the patch I was using from https://www.drupal.org/project/facets/issues/3052574 🐛 Facets with AJAX not working in most of situations Needs work

The combination of patches that others have mentioned does not work for me. I'm able to open the Media Library, but the linkit modal stays open and over the media library when I do so. I can still pick a media entity and click Insert, but no link is created. At most, the link field in the modal gets populated with something like /media/123456, but clicking the green check to apply it to the text that I had previously selected instead inserts a link that looks like /media/123456 and places it at the very beginning of the WYSIWYG.

Production build 0.71.5 2024