I would vote in favour of having redirects of aliased paths working out of the box. If I had a vote!
For the non-technical user building Drupal sites without a developer, the the fact redirects of aliases don't work, and even the concept of an alias, can be confusing.
amber himes matz → credited john_b → .
Thanks. I am certainly open to having help on the project, if that seems likely to provide best value for client.
First I need to make some decisions based on whether we need Commerce at all for our donations (probably yes), and based on how client's recurring donations are currently saved. Not sure whether it is in the third-party hosted donation form, or as Stripe subscriptions. If as Stripe Subscriptions, that is likely the way to go for us for easier migration. Besides, I have found Commerce Recurring challenging.
Note that the same error occurs when the styles/ directory is not writable, see 🐛 DivisionByZeroError: Division by zero in template_preprocess_image_style_preview() (line 51 of core/modules/image/image.admin.inc). Active
The error occurs when the server fails to resolve maxmind's URL. This can result from a misconfigured firewall, for example. The patch #4 applies to D10 and looks right.
Yes I can take over the module, thanks.
Thanks for that. I installed it and ran updb (a mistake, I should have uninstalled 1.7 first). So ran drush pmu google_tag, drush en google_tag.
After that I saw an error 'google_tag_container entity missing'.
At the same time my administrator role and all related permissions were deleted. I am not blaming this MR, especially as I had failed to uninstall google_tag 1.7 before proceeding, and I do not really know the cause, so have not set back to 'needs work'. Just now feeling too traumatized to test again.
That is fine.
Pantheon's response headers delete the popup_message_displayed cookie.
This can be fixed by changing cookie name to STYXKEY_popup_message_displayed.
Ref https://docs.pantheon.io/cookies
and Pantheon Slack (must login) https://pantheon-community.slack.com/archives/C2GJ3JG7Q/p1519853802000551
Not my report, but I am seeing the same issue.
Steps to reproduce:
Put a copy of the site on Pantheon. Their varnish config removes the cookie. Cf. https://docs.pantheon.io/caching-advanced-topics#cookie-handling
Possible solution: use JS cookie detection, as eu_cookie_compliance optionally does. Or allow users to change the cookie name so they can chose a name which can bypass Pantheon's Varnish config.
The issue was caused by a different module.
My patch was buggy.
This fixes the problem for me.
@kopeboy in the setup of the text format which active for node where you want the block TOC to appear, you have check "show TOC in block" before it works. Alternatively you can use the inline option [toc block] instead of [toc]
@catch
I have seen the bug on a monolingual site, on pages with content type='home' which are not front page. However I do not know if it was a white space bug or a %20 bug. I am not aware of any occurrence since applying the white space patch.
The problem node had langcode 'und'. Nodes migated from D5/6/7 have langcode 'und'. Nodes created post-migration have langcode 'en'. In some cases nodes with langcode 'und' redirect to nodes with langcode 'en'.
Shouild be "Critical". Our monolingual site is randomly returning 404s for key landing pages. We will be grateful for a fix in D10, where patch does not apply cleanly.
I have seen the issue on a site which never was bilingual, and uses language undefined. Not sure what triggered it.
Reroll for 8.x-1.7, changing update function name, see #17.
Thanks!
The patch allows 'show per session until dismissed' OR 'show until time expired time after dismissed'. It may make more sense to combine them with AND.
The attached patch does what I requested.
That works, thanks!
This patch works for me.
The problem seems to be that Drupal loads ajax libraries for admin but not for anonymous. Webform loads ajax libraries. So we need to load ajax libraries explicitly if an EBT button is on the page.
Thanks!
Read and tested. Thanks.
@jonathanshaw Thanks for sharing your comment and code!
Did you see https://www.drupal.org/project/eu_cookie_compliance/issues/3295492#comme... ✨ Support for Google Tag Manager's "Consent Initialization" trigger Active
and https://www.drupal.org/project/eu_cookie_compliance_gtm/issues/3332626 ✨ Make the module compatible with Google Consent Mode RTBC
With Google Consent Mode 2, as well as setting the cookie, you have to include flags in the data you send to Google showing what level of consent you have obtained. Are you doing that? The basic method is shown at https://developers.google.com/tag-platform/security/concepts/consent-mode
As I recall, EU Cookie Compliance does not handle modeling the data which is sent to Google, which is part of this process. This data is not sent on the basis of consent / no consent, but is added to the data which is sent IF consent has alrady been given. To be clear, I have not implemented this, though I have worked with EU Cookie Compliance.
If you have evidence for your claim that counting is correct when you receive > 1000 visits per day, that proves I am wrong with my suggestion that you are not sending the correct data.
Attached patch adds a checkbox which makes the addition of a radom string to each footnote ID optional.
It was spam. Visiting the site advertising injection moulding machines does not illustrate WPMU.
WordPress is pretty horrible really for multiple reasons. I do a lot with it because clients have it. And Drupal 10 is infinitely more stable than early D8, even if it is ludicriously complex for small sites. However, I discovered this week on a D9 to D10 upgrade that 'Composer hell' is still a risk with Drupal.
Thanks. Tested in both Gin admin theme (child theme of Claro), and in Stark theme. It is fine.
I am on current D10, 10.2.5.
Steps: set admin theme to Claro or Gin; install the module. Set to use the external validator.nu. Vist /admin/reports/w3c_validator. Click to validate all pages.
A bit abusive I know but I was struggling to install the binaries, HTML5 validator seems to need Java, and even the Debian package for the HTML4 validator was a struggle to get working. I was not banned but the validator tended to return a 502 from time to time. Anyway I completed one run.
Reload /admin/reports/w3c_validator. See WSOD with 'Website has encountered an error, please try again later.' Check db log and see error in the description. Switch admin theme to something else, like Stark. The result of the validation run appear. Set admin them back to Claro or Gin. See WSOD again.
Assume you cleared caches? That is usually the first step with Drupal.
If you look in the browser Dev Tools under Network you will probably see that the CSS and JS files are returning 'Permission denied', possibly 'Not found'. If that is what you see, it is not a Drupal issue. It is a server misconfiguration, such that the web server has no permission to serve the CSS files, owing to their ownership. Talk to the person who set up the server, rather than looking for a Drupal-specific solution.
The method getVocabularyId existed in Drupal 9 but has been removed from Drupal 10. It sounds as though you have some code in your codebase calling this method. Therefore you should find where that code is and if it is a module, uninstall the module where it is found.
John_B → created an issue.
There is a core issue for this 🐛 Call to a member function getCacheTags() on null Needs work . It says "The root cause is a missing image style defined somewhere in your configuration, which can be exceedingly hard to find without enabling Xdebug, setting a breakpoint, and stepping through the code.
Once the offending (missing) image style machine name is uncovered, the fix is fairly trivial, to manually go create and configure the missing image style. "
The issue contains a patch (though of course you would prefer not to patch a core module) and other advice (e.g. make sure thumbnail image style exists).
The above patch does not work on 8.x-1.7 as google_tag_update_8104() is now declared twice.
In case someone wants to use the idea I suggested in #3224559: Invalid HTML causes errors → of calling the PHP HTML Tidy extension, here is a patch which does that.
It seems that Html::normalize in TocBuilder.php is fixing mismatching tags when using PHP's DOMDocument class for HTML, as Drupal 9 does.
As a result, toc_api module is fixing broken HTML which would not be fixed by Drupal's core 'Fix broken HTML' filter.
However, this function is not fixing mismatching tags when using Mastermind/html5-php, used by D10's html utility.
John_B → made their first commit to this issue’s fork.
Look at your status page under Reports > Status and check that the php version is at least 8.1 and that the required php extensions (in this case probably GD) are present on the server. It is probably not that but worth checking basic requirements first.
In php sometimes the opcode cache gets corrupted. It is rather rare if you are using PHP's built in opcode cache.
You can call individual cron jobs if you have ultimate_cron module.
Indexing the site not using cron does not seem realistic, and probably would not help. Your mysql is falling over when using cron--why would it not also fall over when running the mysql commands without cron? It probably would, and the server resources or configuration need attention.
I should add that the above problems only occur if the "Add line breaks" filter runs after the footnotes filter. To my mind, it is OK to require it to run before the footnotes filter, if it is documented. This does work if debug is disabled. Therefore setting to RTBTC--though the limition does need to be documented.
Many thanks.
Turning off debug mode deals with most of the <br> tags. It fixes the formatting problem for the footnote reference in the body text.
There is still one br tag between footnote number and fonte text, as follows:
<li class="footnotes__item-wrapper js-footnote-reference ">
<span class="footnotes__item-backlinks"><br>
<a class="footnotes__item-backlink js-is-auto" href="#footnoteref1_jV2bEcWE6rfv" id="footnote1_jV2bEcWE6rfv">1</a><br>
</span><br>
<span class="footnotes__item-text">Footnote text.</span>
</li>
This creates a problem with the footnote grid, as shown in the screenshot:
The new version is not an issue for us if we can plan our content creation workflow on the basis that 3.x., which works very well, will not be abandoned.
By messed up I mean the following. My node content is as follows:
Body text.<footnotes data-value="">Footnote text.</footnotes>
If the core "Convert line breaks" filter runs after the footnotes filter, the footnote is printed to the browser as follows:
<li class="footnotes__item-wrapper js-footnote-reference ">
<span class="footnotes__item-backlinks"><br>
<a class="footnotes__item-backlink js-is-auto" href="#footnoteref1_mUdvmeD9P6xi" id="footnote1_mUdvmeD9P6xi">1</a><br>
</span><br>
<span class="footnotes__item-text">Footnote text.</span>
</li>Those br tags cause the footnotes.css grid to output the footnote in a narrow column, as in the screenshot.
A content editor not using CKEditor is no edge case. It was Drupal default until D8. There must a lot of legacy countent out there from the two decades from the start of Drupal to D7 EOL in 2025, using Drupal < D8's non-WYSIWYG default. This content may suffer during migration from D7. Drupal during those two decades has claimed 'we will break your code but we will never break your data'.
For the sake of argument let us say it is an edge case. Let us say content editors should not be inserting line breaks, and that it is now OK to break legacy content. We then have a Footnotes filter which works correctly with perfect markup, but is fragile, because it can be broken by a small error in markup. This is not ideal and should at least be documented.
The problem with ouputted markup messing up the footnotes.css grid, if the core line break filter runs after Footnotes filter, should also be documented.
John_B → created an issue.
I have tested and looked at the commits. I think it is fine.
Marking it a RTBTC though I have one reservation, arguably a sepearate issue: the markup breaks in a strange way if core filter Convert line breaks into HTML (i.e. <br> and <p>) runs after Footnotes filter.
I think the latest patch is basically usable and we have used in production for over a year, so setting to needs review. There are edge cases where it will not do everything a user wants, but that is not a bug.
If a heading text appears twice, auto-generated IDs based on the heading text must be unique, so an -01 should be added the second time that text us used to generate an ID
Also, if the markup contains an ID which is used more than once, which is of course incorrect HTML, the second copy of the ID should be modified by the module by adding -01.
There is a bug because in certain cases the -01 is being added where it is not required.
The problem is that in src/Toc.php, the line while (isset($this->ids[$id]) || isset($this->existingIds[$id])) { the part
isset($this->existingIds[$id])) is returning TRUE for IDs which are not in fact duplicates. Once that is removed, the -01 is added only where there really is a duplicate ID, or a heading with duplicate text from which we risk creating a duplicate ID. A patch is attached.
Note that Drupal 10 rewrote the core HTML utility, which is used to parse HTML. There are significant differences and this can create bugs. I have not checked whether the problem arose on D9.
The aim of the ticket was to ensure that footnotes which include line breaks work. Using the MR, footnotes containing one or more line breaks do not work either in data-text or inside the <footnotes> tags..
If the purpose of the MR was to make the Drush command convert line breaks to markup, that worked when I tested it. I have not read into the code.
To be clear I have not tested the latest MR with --use-data-text=TRUE, only with --use-data-text=FALSE.
Thanks.
The latest MR replaces line breaks and so on with tags. There are two problems here:
Problem 1. Footnotes containing <a> or <strong> tags work, but footnotes contaning a <h> tags or <br> or a <br /> or a single or pair of <p> tags or a pair of <ul> tags, and possibly other tags I have not tested, break either the body text or the footnote text in various ways.
In the db log I see
Message Warning: DOMNode::appendChild(): Document Fragment is empty in Drupal\footnotes\Plugin\Filter\FootnotesFilter->process() (line 164 of ~/footnotes/src/Plugin/Filter/FootnotesFilter.php)
Warning: DOMDocumentFragment::appendXML(): ^ in Drupal\footnotes\Plugin\Filter\FootnotesFilter->process() (line 161 of ~/footnotes/src/Plugin/Filter/FootnotesFilter.php)
Also above message with nothing instead of ^. Three is no ^ in my markup.
Warning: DOMDocumentFragment::appendXML(): Entity: line 18: parser error : chunk is not well balanced in Drupal\footnotes\Plugin\Filter\FootnotesFilter->process() (line 161 of ~/footnotes/src/Plugin/Filter/FootnotesFilter.php)
Problem 2. Arguably not a fatal problem, but for a content editor working with complex markup within footnotes, stripping all line breaks, and imposing a rule that no line breaks may be used within the markup, makes the markup diffiult to read and edit.
It is a separate question whether a fault in the markup should be tolerated, or is allowed to break a page using the filter. The toc_api module in D8+ switched to using core's HTML utlility, and started breaking on faulty markup. For now we are still getting problems with correct markup.
John_B → created an issue.
scott_euser → credited John_B → .
We are adding @ as delimiters around text which a filter should process. As it happens, that filter is turning the delimited text into a link.
When our delimited text is added inside <foonotes> tags, our problem clears up. The text delimited by @...@ is converted to a link by our custom filter.
When adding the same text inside the data-text attribute, the @...@ are simply printed to output, and not processed by the filter.
We could use different characters as delimiters, and update all legacy content. I have notg tested using other delimiters.
Separate issue, but I am also concerned if we upgrade footnotes using this drush command, and a year later the content creators decide they want to start using CDEditor.
Many thanks. I finally got round to testing. Sorry about the delay.
This does not work where there is a line break before the start of the footnote text.
For example, this works:
Here is some body text.<footnotes data-value="">Here is some footnote text.</footnotes>
When editors are working without WYSYWIG, they will add line breaks for better layout.
Here is some body text.<footnotes data-value="">
Here is some footnote text.
</footnotes>
When using the above the footnotes are empty. DBlog says Warning: DOMDocumentFragment::appendXML(): ^ in Drupal\footnotes\Plugin\Filter\FootnotesFilter->process() (line 161 of /home/website/dev_html/web/modules/contrib/footnotes/src/Plugin/Filter/FootnotesFilter.php)
Many thanks.
Converting text between delimiters can cause problems. We do convert text between @...@ using custom code. If it becomes a probem will configure more unusual characters as the delimiters.
This kind of thing is not unusual. Mathjax does it on the frontend to format mathematical notation. There is no documentation indicating whether Footnotes 3.x. supports it. However, it did not break Footnotes 3.x. There are many other situations where HTML which does not comply strictly with the HTML 5 standard works, and is used. CKEditor 5 and Guteberg both use far wilder non-standard HTML than this.
I am grateful that you are so responsive. A look around our content heavy site will show many examples of complex footnotes. Whether we should use a WYSIWYG is an open question, but if Drupal works without one, Footnotes ideally should too.
Here is a piece of HTML outputted by the drush command.
<footnotes data-value="" data-text="@Malaria Consortium’s seasonal malaria chemoprevention program: Philanthropy report 2020@, Pg. 5."></footnotes>
I don't what the expected output is. I do know that the inclusion of a real apostrophe in Consortium’s as distinct from a fake / keyboard apostrophe, is enough to break footnotes when using 4.x but not when using 3.x.
You can see an example of the extra space at start and end of the footnote text at https://www.drupal.org/project/footnotes/issues/3414604#comment-15397449 🐛 Support adding the text content within the element Fixed . If 4.x. is going to turn this extra space into
tags, in a way that 3.x. did not, that space should be removed, and documetation should warn content creators to stop adding such space for clearer layout.
The delimited by @...@ is converted to links to the sources table.
if you compare the HTML source which I pasted at
https://www.drupal.org/project/footnotes/issues/3414604#comment-15397449 🐛 Support adding the text content within the element Fixed with the HTML source of https://www.givewell.org/charities/malaria-consortium you can how the link is grabbed from the Source table at the bottom of the page, and used to turn delimited text into links.