Will trigger trigger 2.0.2 release.
The form shouldn't fail with unexpected inputs either, meaning both an update and a fixed form is needed.
Leaving on NR for feedback, but this should trigger a new release soon.
Updated code and releases to follow.
8.x-1.x branch code can handle the missing value. This update will fix it for the 2.x branch, triggering a release.
A hook_update_N would be the better way to handle that. It's missing config specified in the schema that should be there.
Release prior to new branch, or along side a less trivial issue.
This works as advertised.
It should be noted that this eliminates the password strength meter.
Potentially, there is a core issue which would replace the entire password confirm anyway: 📌 Replace confirm password field with show/hide functionality Needs work with draft change record Added a new password element 'password_unmask' and deprecating the 'confirm_password' element. →
MR22 is pending review to be ported.
Updated summary with link to issue with reason as to why this has happened.
The test-only job fails as expected.
https://git.drupalcode.org/project/views_advanced_cache/-/jobs/5589448
1) Drupal\Tests\views_advanced_cache\Functional\ViewsCacheMetadataTest::testCacheMetadata
Behat\Mink\Exception\ExpectationException: Current response status code is 500, but 200 expected.
This is a bug preventing the module from working for new uers. As such, merge and release immediately.
Update summary.
Needs a test to make sure it doesn't hit again.
@nicxvan That CR would have turned up in my search ok and it contains enough information for a user to understand what happened. It's currently showing up in the search index too, just a few rows down.
It has a link to the old CR which should perhaps link to the original issue instead.
I searched for "drupal change record formalter attribute" to find the obsolete CR, purely based on the content of the page as it has no fancy url alias.
If the page is deleted and the crux of the CR noted on another one, then that's where that such search will go in the future. There would be no need to dive into doing a redirect when there is no drive for users to hit the old link.
Given the options, and the general practice of removing obsolete CR, then adding details to one of the CR that will remain is the better option.
Going to leave this issue open as you did create a new one instead of adding the patch to #3358555, making me think that it's not possible for you to add a patch file to a "fixed" issue.
When you're done with it, set status to "Fixed".
Additional permissions have been granted, stable releases made, and project opted into security coverage.
Your site will need an update to go from the config from the original patch on #3358555 to what ended up in the final patch in 8.x-1.0 or 2.0.0. There's also a bug in the patch from #3358555 where if the "pages" config is empty, it is still used in the matching logic.
If you were relying on "disabled = TRUE" then the logic will also silently reverse as the outcome of $negate = $this->config->get('negate') ?? FALSE; will be FALSE.
There will a non-zero number of sites using the original patched 8.x-1.0-alpha6 other than yourselves and I'd rather not have sites ending up with unexpected behaviour.
The patch will still be here, but I seem to have usurped your issue of just posting a patch with the realisation that there needs to be a hook_update_N to fix the config for any of those sites.
That's good news because I would have missed updating the config key for those sites again in 📌 Use ConditionManager instead of custom code Active which will once again need to change the configuration.
All good here @suzymasri. Just fixing up my muck up 📌 Method to bypass redirection (Temporary) Active so there will be another release very soon.
If you could as a maintainer:
- update the default branch to 2.x in https://git.drupalcode.org/project/m4032404/-/settings/repository#branch...
- turn off "Enable merge trains" in https://git.drupalcode.org/project/m4032404/-/settings/merge_requests
2.x is where MR should default to, and there's no need to default to using merge trains in a project where only a single MR is probably going to be merged at the one time. Nothing more annoying than accidentally starting a merge train as it's 3x pipeline runs instead of a 5 second immediate merge.
If this patch was used on a production site, it will need the update introduced in 📌 Method to bypass redirection (Temporary) Active
I've tested this here locally both with and without the "disabled" key and it's working to fix up the config here. Can you use this to patch onto 8.x-1.0 and get it working?
Since using ✨ Method to bypass redirection RTBC was widespread, this should be merged and released quickly to help out others trying to update.
2 stable releases today:
- 8.x-1.0 supporting Drupal ^8.7.7 || ^9 || ^10
- 2.0.0 supporting Drupal ^10.3 || ^11
Project has been opted into security coverage.
✨ Method to bypass redirection RTBC was merged into 8.x-1.x branch and released as 8.x-1.0: https://www.drupal.org/project/m4032404/releases/8.x-1.0 →
What is the cause of needing to be patch off 8.x-1.0-alpha6 instead of just using 8.x-1.0?
Is it because of the use of a patch in production using the different config name for negating the path matching? I hadn't considered that it would need a update to help sites using patched version move to main line. It probably does need one.
Releases made.
Still pending 💬 Stable 8.x, 9.x, 10.x, 11.x release with security coverage Active
I just re-read my permissions and it turns out I have been granted the ability administer releases already - sorry about that as it's hard to tell from my account what I have been granted to do on a project as I don't want to step on toes by over-reaching.
Without "Edit project" I'm not meant to be opting the project into security coverage, but that's was the goal of 💬 Stable 8.x, 9.x, 10.x, 11.x release with security coverage Active .
Anyway, let's go make those releases.
We're all prepped to release: 🌱 8.x-1.0 and 2.0.0 releases Active
2.0.0
Drupal 11 compatible release of 403 to 404 module.
Contributors (2)
Changelog
Tasks
- #3431768 → by elc, realityloop: Drupal 11 compatibility and code update.
8.x-1.0
Bug fix and Stable release of 403 to 404 module.
Fixes bug on a routes protected by CSRF which would erroenously be converted to
a 404 error instead of handled by the CsrfExceptionSubscriber.
Includes new features of path based filtering to bypass the 404 conversion, and automated migration from Drupal 7 to Drupal 8/9.
Future development will be on the 2.x and later branches.
Contributors (11)
elc → , avolkman → , hotwebmatter → , omkar.podey → , soni.rashu → , avpaderno → , a.aaronjake → , jeroent → , paranojik → , eduardo_8824 → , ericgsmith →
Changelog
Bugs
- #3483281 → by elc, paranojik, eduardo_8824, ericgsmith: Exclude routes handled by CsrfExceptionSubscriber.
Features
- #3358555 → by avolkman, elc, hotwebmatter: Path based method to bypass redirection.
- #3253529 → by omkar.podey: Migration from D7 to D9.
Tasks
- #3525956 → by elc: Add .gitlab-ci.yml. Enforce uses ordering.
- #3350559 → by soni.rashu, avpaderno, a.aaronjake, jeroent: Fix the issues reported by phpcs.
To be released as 2.0.0.
Follow up 📌 Use ConditionManager instead of custom code Active
Hi @suzymasri ! Glad to see you're still around. I had lost hope and was just waiting for the clock to tick down.
I've only been granted some of the permissions needed to be a co-maint as I can't currently make releases, re-open issues, or edit the project page to "Opt into security advisory coverage".
The default branch will need to be switched over to the new one when I get that far too, but that can be handled by yourself or @skwashd when it comes up. It requires maintain maintainers permission for me to grant the ability to do it.
Thank you!
Slightly re-ordering this so that .gitlab-ci file ends up in its own commit.
I've just taken up the mantle, but I'm still on hold until 20th June (1am GMT+10 + admin time) pending @suzymasri responding here:
💬
Offer to co-maintain 403 to 404
Active
They've logged in this past October 15th 2024, so it means waiting out another 14 days after the initial 14 days waiting for their reply. As best I can tell, Suzy doesn't work at the same company any longer so they're probably not getting the emails, but that's just the rules.
Dave (@skwashd) did respond via email, but he's deferred management of the module maintainers over to Suzy, who was directly looped into the email. Alas, no response that way either.
Anyway, I've got the 8.x-1.x branch fully patched up ready to push and release (along with updated code for each of the RTBC issues to push so it's all hunky dory), and a new 2.0.x branch with Drupal 11 support ready for release too.
Those will be released on the 20th, and I'll be opting the project into security coverage.
Minimum supported core will now be 11.2 as that OOP hooks have been updated again.
Removing planned headless login endpoint, deferring instead of drupal core for that.
Cherry-picked to 2.0.x and 2.1.x.
Remove from development branch.
No rush on making this into a release.
While I did have an email exchange to David, he deferred to Suzy on the matter of becoming co-maintainer and looped in their email address. I have not received a response from Suzy from either that email or the d.o contact form.
No response on:
- #3253529: Migration from D7 to D9 →
- 🐛 User logout without CSRF token redirect to 404 Active
- ✨ Method to bypass redirection RTBC
- 📌 Fix the issues reported by phpcs Active
- 📌 Automated Drupal 11 compatibility fixes for m4032404 Needs review
- 📌 Add GitlabCI testing Postponed
- 💬 Stable 8.x, 9.x, 10.x, 11.x release with security coverage Active
Not going to have any more posts on here as there is a stable Drupal 11 release out.
D11 support was added to the 2.1.x-dev branch.
A headless login can be achieved using the existing drupal core headless login. Adding yet another login method is adding complexity and duplicating functionality when it doesn't need to be. This patch also appears to bypass the login ticket which is a required step.
The following can be achieved because this module functions by authenticating a user against the CAS Server site.
1/ Use the drupal core headless login to get an authenticated session
2/ Access /cas/login?_format=json&service=https%3A%2F%2Fservice.example.com to get a ST
Marking as CWF for now. A pressing need and a re-roll against 2.1.x branch would peak my interest again, but I am also currently considering removing the separate login form and using the drupal core one with a destination parameter set so that 💬 Compatibility with TFA module Active is easily supported. Again, the login form is duplicated functionality.
Having just found out that these new attributes have been removed, I'm very glad that the change records were not deleted and have been marked as [Obsolete]. If they'd been deleted I'd still be searching for signs of them.
I only had a passing recollection of what I had seen in a change record so I searched for it and found these two. From there I now know that I can just use [Hook] because the [FormAlter] didn't survive, and I can read the issues around to check on any future plans for them. It helps to plan out the best way update modules to be compatible with future cores.
It also serves as a more public "Tried this, didn't work" than a closed issue.
Like the entire module, needs tests. 📌 Write tests Active
Re-worded the settings form based on the actual function of the module, but it might need more explanation a la 📌 Improve documentation and describe use case for home links functionality Active
After investigating in #3438836-3: Improve documentation and describe use case for home links functionality → , the "Home Links" part of the module doesn't currently function so that should be fixed as part of this.
That would indicate that very few sites are using the setting.
This changes all instances of /<front> found by a OutboundPathProcessorInterface into the value from /front_page:home_link_path if set.
https://git.drupalcode.org/project/front/-/blob/10.x/src/FrontPagePathPr...
It does not limit based on users, and will trigger if front_page:home_link_path is set to anything.
I also cannot get it to function at all. All of my links to show up as / and not /<front> meaning they just link to the normal front page set in the "Basic site settings" /admin/config/system/site-information.
The ($path === '/<front>' || empty($path)) check might have worked back in Drupal 7, but it does not work now. The condition needs to be changed so it will actually match up to the latest core. Documentation states that:
string $path: The path to process, with a leading slash.
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21PathProce...
Meaning that the path with either be "/" or "/whatever", and never empty or "/<front>"
Further, when testing with the rest of the Front Page module enabled, it makes for a confusing workflow. After arriving at the site and being routed based on role to your front page, all of the links that would return you to it have been replaced with the value configured in home links. It makes the front page redirect a one-shot.
As the functionality operates in conflict with the main function of the Front Page module,
✨
Move "Home links" functionality into a submodule
Active
makes a lot of sense. Perhaps the functionality could be fixed and the sub-module added but only enabled when there is a value in front_page:home_link_path.
Use case is in the situation of a splash page that all users should visit, followed by a home page that all users should be returned to when they click a home page. Without the rest of the "Front page override" enabled.
Issue working branch should be named something unique, such as 10.x-3448931-fixconfimport instead of matching an upstream release branch name. In this case calling the issue branch 10.x means that people have to manually intervene in their local repo to be able to pull and push from different branch names.
Re-rolled for recent release. Fixed up comment wrapping. Patch works for me on a new site before the settings have been saved.
This begs the question, why doesn't this module have a default config for install?
Pipeline confirms these issues have been fixed as a result of other issues.
https://git.drupalcode.org/project/front/-/pipelines/485919
One remaining spelling issue, plus the bad correction that needs to be reverted 🐛 Revert fix of spelling which was an update to fix spelling Needs work
After consideration, the project page is fine. Better to give people the information they need then and there rather than bump them off to other parts of a site.
Response from Dave Hall yesterday; Referred me to and looped me in directly with suzymasri for module maintenance.
Pending reponse from suzymasri.
Add phpcs.xml with uses ordering enforcement.
Contacted skwashd via davehall.c.a/contact
skwashd does not have contact form enabled.
Contacted suzymasri via d.o contact form.
Original patch works as designed.
Fixed existing tests to work with this change, and then added test specifically for this issue.
@berdir Which are the open issues regarding the report page you are referencing?
@cmcintosh The scan is only triggered by visiting /admin/reports/redis and no other tools.
The protected method scan() is only called by \Drupal\redis\Controller\ReportController::overview(). Do not visit the page and it will never be called.
Fixed summary.
Works with PhpRedis 6.0.16 at least. No need to log connection failures - a failure here is fatal by design.
You probably didn't have anything cached at first, or the settings related to using redis hasn't been read yet. With aggressive caching of php files, changes to config file won't be read until the apcu cache is flushed.
elc → changed the visibility of the branch 3337750-divisionbyzeroerror---problem to hidden.
Sorry, mucked up for the MR44 because of the branch name being the same as the parent branch and I wasn't specific enough when pushing the updated MR as I had to use a different local branch name.
I made no changes to the code, just updated the MR with recent parent branch changes. Works well for me.
Thank you for your contribution! Alas, it seems it was not integrated into the module in a timely fashion and now Drupal 7 is no longer supported.
The functionality you seek has been implemented in the supported branch here:
✨
Method to bypass redirection
RTBC
This does not seem relevant any longer.
D7 is no longer supported, and the D8+ version uses an event subscriber triggered on all 403 errors. The site_403 parameter is not used in this version, so there would not be a reason to include it in an admin form.
The site_403 path would only be used once these issues are merged:
🐛
User logout without CSRF token redirect to 404
Active
✨
Method to bypass redirection
RTBC
Looks like this would be quite possible. Also would be possible to release the current as supporting 8.7.7 -> 10.x, and the create a 10.3 to 11.x release with the boiler plate removed.
Tests were fixed in 📌 Automated Drupal 10 compatibility fixes Fixed
Upstream tests have been fixed, so tests now pass.
Re-opening this to achieve:
- Reduce the amount of text on the project page to minimum needed to describe the function
- Move the existing use cases and instructions to the contributed module guide → .
There will not be mode code merged into the module, just changes to the presence on d.o.
Project page updated.
Created new task 📌 Update README and project page Active to deal with documentation updates.
Turns out, I am not the maintainer of that document. How do we find out who the maintainer is so that it can be migrated?
Looks like it just needs an update and then added to the new guide as a single page. It doesn't need multiple pages.
Installed and tested with these versions and unable to reproduce. Could you provide repeatable steps to produce the fault?