Maybe this is a documentation issue. I also cannot work out what "Checking this field will allow you to define a view used by the current term and display on all of its children, unless they have their own settings configured" means. What are the children of a view? Or does this mean the children of a term on the vocabulary?
I think it might mean that the taxonomy terms are all children of the vocabulary, so if you set this as an integrated view for the vocabulary itself then you want that same view to apply to all children (terms) unless specific TVI settings are applied to those terms. That probably does make sense if you're setting an integrated view on a term, because terms can have child terms, so it makes sense to apply the same view automatically to child terms. So maybe it's that the same checkbox label is used for the vocabulary itself, where "terms" as "children" of the vocabulary is a strange way to put it.
If that's what it means, it makes sense that you have to check the box before the vocabulary does anything, because vocabularies themselves presumably would never get displayed in a way this module would handle.
1.0.2 works with Drupal 11
1.0.4 works with Drupal 11
Yes, that makes sense, so I guess a D11 version is going to be important
Thanks. That takes me back a bit to working within the frameworks of a certain large commercial software company. "This feature is by design". You realise it's not a bug, it's a feature!
See what anyone thinks. I may get a moment to look at Redirect myself to see if I can propose a MR over there.
The history is that this used to be one of many features in the Global Redirect module, that did all that was needed to ensure you never got identical content from more than one URL. The main thing it did was to redirect /node/n
to the canonical alias chosen for the node, but resolving comment URLs to the original node URL (with an anchor to get you to the right comment) was something else it did.
When moving from D7->D8, Global Redirect was discontinued, and the D8+ version of Redirect included all the features of the old Global Redirect. So it was no longer needed, but for some reason this particular feature was never ported.
It's not a regression at a code level. But in terms of the intent, sites no longer needing two different modules to handle (i) redirection in general and (ii) redirection to a canonical URL for SEO reasons, this feature needs to be included in Redirect to avoid a second module just for this.
Another "task" issue opened to request this issue be moved back to Active: 📌 Reopen "/comment/ID does not redirect to the canonical URL (3495377)" Active
jamesoakley → created an issue.
OK, I couldn't easily test Drupal 8.0.0 because the oldest compatible PHP I could run on my development server was 7.4.
So I installed Drupal 8.9.0, and had the same experience as above.
So what happens to this issue next? I guess it depends:
If the intention was always that comment permalinks would just be routes that redirect to the canonical URL for the page in question (as @berdir explained above), then it either never worked, or regressed somewhere between 8.0 and 8.9. In that case, this remains a Core issue, needs "Needs Tests" adding to spot any future regression, and is "Major" in priority because of the detrimental effect on SEO.
If, in fact, this was never intended for core, then there are two options. Maybe this becomes a feature request for Core. Or maybe it needs to return to the Redirect module, where it becomes a bug report (since it's a regression from the Drupal 7 version).
I think it's over to the Core maintainers to work out what kind of issue this is.
Thanks @berdir
In that case, I'll move this to the Core issue queue and change it to a bug.
I've done a test, and here's how to reproduce:
- Download the latest core release (11.1.2 now) and install a new site with Standard Profile
- Create a new node of type Article, URL alias
/test-article
- Scroll to the comments section at the bottom of the new article
- Create a new comment entitled "Test Comment"
- Click on the permalink for that comment
- Expected behaviour: Browser goes to
/test-article#comment-1
- Actual behaviour: Browser goes to
/comment/1#comment-1
I'll now do some further tests with older core releases, starting with 8.0.0, to see when this regressed (assuming it did work at that point).
jamesoakley → created an issue.
Maybe there's a prior question of whether this module is still needed? 📌 Difference with what is now in core? Active
Looking at this again, as I realise this module isn't yet D11 compatible. Does it need marking as unneeded, or does it need updating to work with D11?
jamesoakley → created an issue.
I'd guess that this very shorthand issue was wanting to ask what the plans are for a Drupal 11 version of this module.
I think this needs rebasing on the current 6.0.x head.
That should now be rebased and good to merge
Apologies for the second merge-request. Working with this updated mix config file, I've discovered that it was a mistake to remove ./components/**/*.css
because those files are not incorporated into the files generated for the ./build
directory. So this latest MR puts that back into webpack.mix.js
.
If you watch the source and the destination, the browser refreshes twice - the first time when you save the source file, the second time when the build process has finished. You do not get an endless loop.
As I understand it, the reason is that the watch process is doing two things.
1. It's watching for source files to change so that it can regenerate the final css, js and resource files.
2. It launches an instance of BrowserSync, which itself needs to be told what files to watch to see when a reload is required.
The first of those is kicked off by this:
mix.sass("src/scss/main.style.scss", "build/css/main.style.css");
for (const sourcePath of glob.sync("components/**/*.scss")) {
const destinationPath = sourcePath.replace(/\.scss$/, ".css");
mix.sass(sourcePath, destinationPath);
}
main.style.scss
links to _init.scss
, which in turn links to the various files (like _variables.scss
) in the base
directory. When any of those files are changed, the css gets rebuilt.
The second of those (BrowserSync) is kicked off by this statement:
mix.browserSync({
proxy: process.env.DRUPAL_BASE_URL,
files: [
'components/**/*.scss',
'components/**/*.js',
'components/**/*.twig',
'templates/**/*.twig',
],
stream: true,
});
That tells it what files BrowserSync will update on.
You would get an endless loop if the first of those steps (watching source files to know when to regenerate the css) watched for the generated files to change.
I'm proposing making it so that the second of those steps (watching files to know when to reload BrowserSync's proxy site) watches the compiled files instead of the source files.
That way, the flow becomes:
- Save a source file
- This triggers the CSS to regenerate
- The regenerated CSS in turn triggers BrowserSync to refresh its styling
This is an improvement on the current flow, which is:
- Save a source file
- This triggers:
- the CSS to regenerate
- BrowserSync to refresh its styling
- If you're lucky, the CSS has finished regenerating before the browser finishes refreshing.
Hi Dan,
If I turn off watching the build directory, but watch the sources, then change _base/variables.scss
, then the browser reloads when that file is saved, but does not reload again after the build job has completed.
As you say, the ideal would be if the reload was triggered by a source file changing, but waited until mix was finished and idle. I don't know if there is any option for that.
So, I'm working on this and I've found a potential problem. If you watch the source files, rather than the generated ones, the browser resync is triggered when you save an updated source file (obviously). That also triggers sass to regenerate the css files.
If I amend a .scss file in components, it mostly works.
If I amend base/_variables.scss
, that's a more foundational file to alter, so requires more css files to be regenerated, which means it takes (in my case) a second or two for sass to do its magic. My browser reloads the BrowserSync page much faster than that. So the page reloads using the unchanged CSS, and I have to hit F5 when the compilation has finished running. Hitting F5 manually defeats the purpose of using BrowserSync.
What this is actually exposing is that there is a race condition with monitoring any source files for changes. It happens that I've now started watching one that will trigger a more time-consuming CSS rebuild, which exposes the race condition. The fact that I get away with it when altering a css file in the components folder - is a fluke.
Happy to keep working on a MR for this, but I'd need a steer as to how it should be solved. I still need a way to update _variables.scss
and trigger BrowserSync. So far, watching the built css files is the only way I can make this work.
@doxigo, that's fair enough.
But, strictly speaking, components/**/*.css
aren't source files. Shouldn't BrowserSync be watching components/**/*.scss
instead?
Which leads to my use-case, and why I wanted to add the build directory: Shouldn't BrowserSync be watching src/scss/base/**/*.scss
as well? In my case, I was changing Bootstrap variables in base/init/_variables.scss
, to fine-tune colour and layout, and having to refresh the page each time.
Whether doing this is wise or sensible, I cannot say - it's why I asked the question.
But I can help with the "exact patch" request.
It looks like this got lost when Global Redirect merged into Redirect. 💬 How to ensure "Redirect Comments To Node" Active
It turns out the feature in the old Global Redirect module was one I requested and then worked on. I'd completely forgotten. #1680978: Request to redirect URLs for comments to the parent node →
jamesoakley → created an issue.
@ravi - you missed
4.
Go to Text Formats and Editors. Edit "Full HTML". Add lots of other buttons to the CKEditor toolbar, so there is more than will fit on the width of the page.
jamesoakley → created an issue.
The old github page linked for PostCSS Preset Env was a repository that has been archived since October 2023. I've changed the link on this page to point to the repository that is currently being maintained.
jamesoakley → created an issue.
@levendclk, there is a fresh and different advisory for Twig < 3.14.1. https://symfony.com/blog/unguarded-calls-to-__isset-and-to-array-accesses-when-the-sandbox-is-enabled
The issue being discussed here was composer configuration for Drupal core that wouldn't let you manually update Twig to 3.14.0 when that was the secured version. That is now fixed, you can update to 3.14.0, and as I've just verified in response to the latest vulnerability you can also update to 3.14.1.
"Drupal core below 11.0.4"
Actually the github advisory says "<=11.04", so even 11.04 is vulnerable and will cause problems.
jamesoakley → created an issue.
It does look rather similar, doesn't it? I wonder if this is why the Drupal 11 compatibility for this module hasn't been progressed - it's just not needed any more.
I too would love to know if this module supplies anything the new core features otherwise miss.
Glad it worked. Stats show it used to be way more widely used, not sure why it's dropped off. I picked up maintaining when a previous maintainer didn't have time to keep working on it, so happy to keep it ticking along. I use it too. Great website - looks like a welcoming and faithful place - have a good Sunday.
Drupal 10.3 mandated having text format settings in the module schema. Can you please check the dev release or the patch I've just committed, then I'll push out a tagged release if this fixes things for you.
Michael, the link seems to have vanished (the mediawiki site is no longer there). I found this in Google https://openlitespeed.org/kb/litespeed-cache-for-drupal-on-openlitespeed/, but that link now redirects to the OLS homepage. Any chance you could put a guide on this website so it persists through any changes to your website?
Strange problem that I haven't met before and others haven't reported. I'll have a look and see if I can find what's wrong. Thanks for reporting it, and thanks for adding the version of core to your issue summary. Have you just installed the module and it's never worked, or has it come with you through earlier versions of Core and you're now having trouble adding this to an additional text format?
Meanwhile, while we wait for RTBC, please could someone link to the exact patch that works. I get that we're using a merge record for this, but for all my site deployments I'm simply using cweagans composer patches to apply any patches I need to core or contrib, and I'm not clear reading this history as to what patch I need to add to my composer.json file.
info.yml. file updated to remove Drupal 8 and 9 compatibility, as well as adding Drupal 11 as suggested by the bot in this issue.
The issue is being left open to pick up future API changes.
info.yml. file updated to remove Drupal 8 and 9 compatibility, as well as adding Drupal 11 as suggested by the bot in this issue.
The issue is being left open to pick up future API changes.
info.yml. file updated to remove Drupal 8 and 9 compatibility, as well as adding Drupal 11 as suggested by the bot in this issue.
The issue is being left open to pick up future API changes.
JamesOakley → created an issue.
"Never normally critical" may generally be true. But what we're discussing here is a security vulnerability fixed and published upstream by CKEditor (in March 2022), leading the Drupal security team to release a core update to ensure Drupal 9.x and above does not use the vulnerable library. Drupal 7 needs this module to power the editor, and this module does not support the versions of CKEditor that incorporate the security fix.
I'd say allowing site maintainers to update the CKEditor library to one without vulnerabilities is more pressing than "normal".
I like that thought, and with some jquery dependencies already in core it shouldn't add much overhead to do it.
If someone wants to propose a simple patch that lets a site administrator opt in to have Scripture links open in a modal popup, I'd be happy to test and commit it once it works correctly.
It seems so, although in your report there's the added detail that the problem may be in the Claro theme, which is why the problem first appeared when it became the default admin theme. Closing 🐛 "Set up database" screen is displayed even when credentials are properly defined Closed: duplicate as a duplicate
I haven't poked about as deeply into the database as you have, but (2) sounds plausible. In my case, I disable the update module in production, to stop someone lazily updating a module within the UI rather than going through composer (in the development environment). The case when I experienced being unable to check for updates ( #3159646: Checking for updates sometimes fails: "Undefined index" in log → ) was on a site where I'd brought the production database (with updates enabled) back into the development copy of the site, and I think there were updates pending at that point as well.
So I can't completely verify your suspicion, but it is very plausible.
An issue I opened, #3159646: Checking for updates sometimes fails: "Undefined index" in log → , could be a duplicate of this (or could be a different problem) - so linking across from here to there just in case.