Account created on 6 April 2008, almost 16 years ago
#

Merge Requests

Recent comments

πŸ‡ΈπŸ‡°Slovakia poker10

Thanks! I have reviewed the last changes and everything seems good. I have also installed the module and tested it manually once again:

1. Module was installed correctly and new link was added to the menu between Configuration and Reports.
2. The link opened the feed, which was populated by 6 regular announcements as of today (which is correct, because the last one is specific for D9).
3. I have also tried removing some announcements from cache and then running cron, which added the missing announcements back.
4. Uninstallation went without problems.

All tests are green. I do not see any other unresolved feedback in the MR or in this issue. I think this is ready for commit - adding a tag for the final review.

πŸ‡ΈπŸ‡°Slovakia poker10

Thanks for addressing the remaining feedback from MR @mcdruid. I have reviewed it again and I think it looks good!

Left four additional comments in MR, but hopefully these are my last points :)

One additional question about security: Do we need to sanitize feed data (such as title, links, ...) on output somehow? I think that twig in D10 does this automatically, so this <a href="{{ announcement.url }}">{{ announcement.title }}</a> may not be the same as <a target="_blank" href="<?php print $announcement['link']; ?>"><?php print $announcement['title']; ?></a> under specific circumstances. There is a direct output of different variables in announcements_feed.tpl.php. What do you think?

πŸ‡ΈπŸ‡°Slovakia poker10

I think this was discussed approx. month ago on Slack (Gitlab initiative) and the outcome was that it would be the best if we can test it + document. See: https://drupal.slack.com/archives/CGKLP028K/p1706272560536979?thread_ts=...

πŸ‡ΈπŸ‡°Slovakia poker10

Noticed one minor typo in MR, left a comment there.

Otherwise +1 from me, it is good to see this moving forward!

πŸ‡ΈπŸ‡°Slovakia poker10

Unpublishing this, as it seems like this should have been reported to the Security team as a security vulnerability.

πŸ‡ΈπŸ‡°Slovakia poker10

Thanks @mcdruid, that is a very good point! I agree we should correct this.

Finally I was also able to do another complex review (including the tests), so I have added comments to the MR - mostly small comments/text changes, but also a few minor code changes. As there are also required changes from #77, moving back to NW.

When making changes - please be aware that the module itself is called Announcements - this is the name displayed in the list of modules in D7 and D10 (not Announcements Feed, or Announce), only the module folder has the name "announcements_feed". Therefore the reference to "announcements feed" is a reference to the feed itself (not to a module name) and I think it should be lowercase.

We would also need to update this documentation page: https://www.drupal.org/docs/core-modules-and-themes/core-modules/announc... β†’ , as the module is still listed as Experimental and the name of the module is wrong (also the name Announce is used on a few places there). I will create an issue for this (as it is mostly related to the D10 module, not this issue).

Once all points are resolved, we will try to get a signoff from @Fabianx and I think this would be ready to go. Then the "Enable by default" implementation will be done in a separate issue once the decision here is made: πŸ“Œ [policy, no patch] Decide whether to enable Announcements Feed for 7.x by default Needs review

Thanks all for the hard work here!

πŸ‡ΈπŸ‡°Slovakia poker10

Thanks for reporting/working on this. The same change seems to be already in D10, see: #2927012: _drupal_log_error() returns a 0 exit code on errors β†’ , so I think this looks good.

Not sure if we can easily backport the test from D10, as we do not have PhpProcess. Any thoughts? Did not have time to look at that more thoroughly yet.

πŸ‡ΈπŸ‡°Slovakia poker10

Thank you both for working on this and also for confirmation that it fixed the private testing for D7. I have compared the MR with the D10 commit code and the changes are the same. Committed/pushed this.

πŸ‡ΈπŸ‡°Slovakia poker10

I think this is a duplicate of: πŸ› Forms with multiple file form elements produce upload errors with the Drupal page cache enabled Needs work . This issue is newer, so closing it. However, the approach here seems to be more reasonable than the attempts to remove the check altogether in the referenced issue.

πŸ‡ΈπŸ‡°Slovakia poker10

Added one comment to the MR about comment wording.

Also, the IS states:

check that there's a record for user 0 and warn the site administrator if not.

However, we use REQUIREMENT_ERROR instead of REQUIREMENT_WARNING in the code. Do we need to update the IS, or change the code to use REQUIREMENT_WARNING?

Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

I think that the removal was discussed in this issue: 🌱 [Policy] Remove tour module from core Fixed

πŸ‡ΈπŸ‡°Slovakia poker10

Thanks! Then I think this is RTBC again.

πŸ‡ΈπŸ‡°Slovakia poker10

@kala4ek Here are some information about the transition from patches to MR: #3412417: Disable DrupalCI testing β†’ , including a possibility to link to static MR diffs (but this needs to be implemented in Gitlab). However linking patches from 3rd party sites is not recommended and you should download a separate copy of the patch locally.

πŸ‡ΈπŸ‡°Slovakia poker10

What will happe, if there will be hundreds of child menu items? I suppose this will not look good. Do we need to print the child menu items?

I think we need to add a test for this new feature, so that we can confirm that the extra message is here, when the menu item has children and that the message is not there, when deleting a menu item without child items. Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

There is a contrib module β†’ , which does this thing. Also it is possible to add this file separately, without the need of any module (and any core hacks). What are the expected benefits for Drupal, if we add it to the core?

The contrib module has a very low usage and not sure, that this file is used by many sites to be something, that would be necessary to have at the core.

I am also a bit confused, if the file is intended to be read by humans (as there is practically no structure in the humans.txt "standard"), would not it be better to generate a page on d.o. with a list of all contributors to the core instead? Such a page would also have a formatting and will be indexed by search engines.

It aims to be customized for each Drupal project with the people involved.

Then I think the scaffold process should not create a file named named humans.txt, but instead example.humans.txt, as the file is not intended to be used without further modifications.

πŸ‡ΈπŸ‡°Slovakia poker10

This URL https://www.drupal.org/contribute/core-maintainers β†’ is also in D7 maintainers.txt file. I think we should set up/restore that redirect, instead of fixing that in core repo. Because evidently the link (or at least a redirect) was working some time ago (https://web.archive.org/web/20230801000000*/https://www.drupal.org/contr...). Moving back to NR to consider this, thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

Adding a note here, that in this Slack thread https://drupal.slack.com/archives/C1BMUQ9U6/p1699266961237289, there were concerns raised about adding so much deprecations (especially for contrib modules). Proposed approach was to either separate deprecations into a follow-up issue, or make the first step without deprecations - just the new functionality. It would also make the reviews here easier.

πŸ‡ΈπŸ‡°Slovakia poker10

Can we add this to 8.x-2.x as well? I think this is pretty important feature request. Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

Thanks for the idea @mcdruid! I like this idea to add a new hook, instead of trying to push all complex changes from πŸ› Filter "Convert URLs into links" doesn't support multilingual web addresses Needs work without proper review / testing (in this D7 phase).

Should we create follow-up issue for this hook implementation?

@charlesc If you would have a minute, can you please confirm, if such an approach will work for you? Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

My personal opinion (as a developer) about ads in general is, that it would be very sad to end up like WP. There are ads everywhere. I do not think this is what we want in the Drupal ecosystem (as mentioned by others in previous comments). I fully support non-intrusive ways of ads/funding, but please, communicate it clearly and add a possibility to turn it off easily (like ✨ Implement a settings pattern for disabling partner banners Active ). Because each client is different and there could be different scenarios, where such ads are not appropriate. Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

@rszrama Thanks for the detailed explanation! I understand the need of funding for modules like Commerce and it is nothing wrong with that. @s.messaris posted a link to the policy about advertising in projects - please, if you find that policy outdated/not good, open an issue in the Governance project, so that there could be a discussion about possible changes. Until then, the policy is in effect (regardless of what the Webform module has or does not have). I am not evaluating the implementation here, I am just making a comment about the current policy.

πŸ‡ΈπŸ‡°Slovakia poker10

The typo fix looks good to me, thanks.

πŸ‡ΈπŸ‡°Slovakia poker10

The MR workflow at drupal.org continues to not provide persistent immutable patch URLs which is hugely problematic when it comes to referencing patches externally, so I'm sure the old method isn't going anywhere while that flaw remains. So long as the traditional patch files are supported I'll prefer to keep using them.

Please follow this issue #3412417: Disable DrupalCI testing β†’ regarding the DrupalCI deprecation.

πŸ‡ΈπŸ‡°Slovakia poker10

My main concern if we set all labels as project-specific is, that it will have a potential to confuse contributors in terms of that the contributing experience will not be uniform anymore.

Currently these settings are similar in all projects and contributors know what to expect (and I think it is good, as all projects are under drupal.org, so at least some uniformity is important). It would not be good if a contributor goes from one contrib project to another and has to explore how differently it goes there. On the other hand, I understand, that there is a lot of non-code projects, where some labels does not make sense.

I think labels like "category" does make sense to be project-specific.

But I would be cautious with "status" label and not sure about "priority" either. Maybe if it would be possible to create them as project specific, but for each project (existing a new) set default values to what we have now, so at least all are at the same starting point (further customization by projects will be ok, but if we do not set the default values, then I can imaging the "mess" it could become in some contrib projects).

I suppose that "version" label will be according to the branch names and tags?

Then there is a question about issue tags - currently you can search all projects for example by PHP8 tag ( https://www.drupal.org/project/issues/search?issue_tags=PHP%208.1 β†’ ). Would this be possible with Gitlab issues, when each project would have a separate issue tags, to do this? I think this is a beneficial feature.

In my opinion this is a trusted role, equivalent to the β€œmanage issues” D.O. permission and should not be granted to general users

Not sure which extra permissions this role has, but currently all contributors could change practically everything in d.o. issues and that is good and contributors are used to it. If we remove this ability, we would move a lot of work to a few maintainers, which would not be good. And we would also need to "re-train" contributors to the new workflow. So I think we need to carefully consider this to do only the most necessary changes (in the first step?). The next step could be to allow to utilize more new Gitlab features and consider, how to do this.

πŸ‡ΈπŸ‡°Slovakia poker10

I think the "minimal" word should be OK, so I changed that on commit. I consider that comment helpful (exactly for reasons mentioned in #10), so not removing it. Other than that I think this looks good and code is the same as the D10 commit (also the CRs are practically the same).

Committed this, thanks all!

πŸ‡ΈπŸ‡°Slovakia poker10

I think that if we agree on a decision here, then we will need to create a separate issue for implementation, as the main issue is just about adding a module itself. And it will be more transparent to have the auto-enable process in a separate issue.

I guess we can use the hook_requirements to check for that variable. I'm not sure how an update.php or drush updb will behave when an error is defined in the hook. We just want to skip the installation, but it's not an error.

Could not we just do the check in the update hook? If we add a condition around module_enable() directly there?

πŸ‡ΈπŸ‡°Slovakia poker10

Yes, the variable that would only prevent the installation, if the change is made BEFORE running site updates. There can be sites, which for various reason do not want this enabled by default (maybe some company policies, etc..). The release notes could mention this and each site which will set the variable will not have the module enabled when updating the Drupal version. It would have no effect when installing/uninstalling via UI.

πŸ‡ΈπŸ‡°Slovakia poker10

Something similar happened in the Commerce module recently, where they decided to enable similar functionality by default for all existing sites: πŸ“Œ Document the communication to 3rd party sites Active ( https://www.drupal.org/project/commerce/releases/8.x-2.37 β†’ ). I mention it here just for info and we can probably learn some lessons from it.

I think we would need a very good communication/explanation and we also discussed a possibility to opt-out of this behavior via a new config option in settings.php. So that sites that would not want to enable the module automatically would be able to set this and it will cause the installation process to be skipped.

πŸ‡ΈπŸ‡°Slovakia poker10

Thanks for providing additional information. I debugged this based on your example and it seems like the problem is that D7 does not have "u" modifier on the pattern.

There is an issue which added this to D8+, but this issue was not backported to D7 yet, see: πŸ› Filter "Convert URLs into links" doesn't support multilingual web addresses Needs work

So currently the D10 has this (see the second row):

  $url_pattern = "[\p{L}\p{M}\p{N}._+-]{1,254}@(?:$email_domain)";
  $pattern = "`($url_pattern)`u";

And D7 this:

  $url_pattern = "[\p{L}\p{M}\p{N}._+-]{1,254}@(?:$email_domain)";
  $pattern = "`($url_pattern)`";

When I added this "u" modifier manually to test it, the email address started to display correctly again.

The question is, whether we can finish and backport the πŸ› Filter "Convert URLs into links" doesn't support multilingual web addresses Needs work into D7 (so we would have a full fix available), or if it would be easier to just add these modifiers without any side effects, if the rest of the fix from the mentioned issue will be not backported. Currently I do not have a full knowledge what impact could have adding that modifier, so need to discuss this further.

πŸ‡ΈπŸ‡°Slovakia poker10

The fix from #2 will only hide the underlying problem, so I would not recommend to use it. The DrupalDatabaseCache::getMultiple() method is supposed to return an array, therefore such fix should not be needed. We would need more informations as per #4. Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

Thanks for reporting this. Can you please provide more information and steps to reproduce?

I launched Drupal 7.98 on simpletest.me and with filtered HTML format tried to save "δΈ­ζ–‡abc@example.comδΈ­ζ–‡". Only the "abc@example.com" part was converted to email address. Then I tried the same on Drupal 7.99 and the result was the same. Text format configuration is default (clean installation).

It would be great if you can provide information which text format are you using, what is the configuration of that text format and what is the real vs expected output on each Drupal 7.98 and 7.99. Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

Drupal resizes it to have 1620 pixel as height, but its new length will be 2'430 pixels in order to preserve the aspect ratio...too small!

Yes, that is correct. This fix changed the behavior in D7 to align with the D10, as the resulting image should not be smaller than minimal dimensions, even if auto-resized.

πŸ‡ΈπŸ‡°Slovakia poker10

Thanks for reporting this. Can you please create a new issue with your description + image? It seems like it would be ideal if only one message is displayed, to not confuse users. You can post the link to the follow-up issue also here. Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

Parent issue was fixed, so moving back to needs review, as we should compare with D10 patch which was committed.

πŸ‡ΈπŸ‡°Slovakia poker10

We can try it, but I do not think so, because when I raised this question here: https://gitlab.gnome.org/GNOME/libxml2/-/issues/615, the answer was it is not a bug, but a deliberate change in the library.

πŸ‡ΈπŸ‡°Slovakia poker10

If the fix is relevant for the development branch as well, then the correct workflow, according to the Backport Policy ( https://www.drupal.org/about/core/policies/core-change-policies/backport... β†’ ), should be:

1. Prepare a patch/MR against the development branch, which is 11.x-dev currently
2. Committers will commit the fix to this development branch
3. Committers will then cherry-pick the fix to stable branches (such as 10.2.x-dev), if the change is allowed there

Therefore the main MR should be the 11.x one, as that will be the starting point.

πŸ‡ΈπŸ‡°Slovakia poker10

There seems to be the MR !4164, which is for 11.x - that should be the main MR.

Patches are deprecated and drupal.org is going to move to MR-only flow sooner or later, so I am hiding all patches to clean this up. If you want to include a patch from MR, you need to download it locally, see: https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... β†’

It's strongly recommended to lock the patch file versions on production sites. To do so you must download the patch file and use it in composer from a local directory. If you use the URL to the Gitlab MR directly, your codebase will change without warning, as people work on the merge request.

πŸ‡ΈπŸ‡°Slovakia poker10

Yes, but according to this: https://blogs.oracle.com/mysql/post/introducing-mysql-innovation-and-lon... , 8.2 is not a LTS version, so I am not sure if it would have any benefit to require that.

In case there will be the next LTS (probably MySQL 8.4) available by 11.x beta, that would probably make sense.

πŸ‡ΈπŸ‡°Slovakia poker10

This is not a deep performance benchmark, but I can confirm that the MR !4110 is working on few our sites with thousands of taxonomy terms. Before changes from MR were applied, there was an OOM error on the taxonomy overview page (admin/structure/taxonomy/manage/vocabulary/overview). After applying the changes, the page is working again.

I think a more detailed benchmark could help for this to be committed (for example memory usage on that page before/after, etc..), as there is a "needs profiling" tag, but otherwise I think this works pretty well.

πŸ‡ΈπŸ‡°Slovakia poker10

There is a failure in the MR pipeline, which does not looks like a random one, but related to the MR changes:

There was 1 error:
    
    1) Drupal\Tests\file\Functional\FileFieldDisplayTest::testDescToggle
    Behat\Mink\Exception\ElementNotFoundException: Button with
    id|name|label|value "Save and continue" not found.
    
    /builds/issue/drupal-2320877/core/tests/Drupal/Tests/WebAssert.php:144
    /builds/issue/drupal-2320877/core/tests/Drupal/Tests/UiHelperTrait.php:78
    /builds/issue/drupal-2320877/core/modules/file/tests/src/Functional/FileFieldDisplayTest.php:178
    /builds/issue/drupal-2320877/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

https://git.drupalcode.org/issue/drupal-2320877/-/jobs/507087

πŸ‡ΈπŸ‡°Slovakia poker10

According to the Google robots.txt description here: https://developers.google.com/search/docs/crawling-indexing/robots/robot... , the /search should match any path that starts with /search. So I do not think we need both /search and /search/ (and similar for the second change). The rules from robots.txt should be the "starts with" rules.

The second question is, we have /admin/ in robots.txt. /admin path is valid as well, so why we are not changing this too?

πŸ‡ΈπŸ‡°Slovakia poker10

I have created a simple draft CR here: https://www.drupal.org/node/3409738 β†’

And also created two follow-ups to fix the behavior of the test-only job from above here:

πŸ› Test-only job reverts unrelated changes in non-rebased MRs Active
πŸ› Test-only job does not detect failures correctly Active

πŸ‡ΈπŸ‡°Slovakia poker10

The MR is not rebased, but I thought we fixed that in πŸ› Test-only job shouldn't require constant rebases to detect which files were changed. Active , so there is no need to rebase when running test-only pipeline.

πŸ‡ΈπŸ‡°Slovakia poker10

Thanks for working on this. The tests failes on the MR, so moving to Needs Work, see: https://git.drupalcode.org/project/drupal/-/merge_requests/5735/pipelines

There are coding standards issues and I think we are still removing too much t() usages - the title suggest that we should only remove "uses of t() in assertEquals() calls" (if the title is incorrect, we need to update the title). Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

Corrected D7 EOL date in heading.

πŸ‡ΈπŸ‡°Slovakia poker10

adding new features to Drupal 7 (including full support for PHP 8.3 or newer versions),

We will try to make D7 core compatible with PHP 8.3 as it is one of the priorities for the next release. There are only one or two issues left, see: 🌱 [META] Make Drupal 7 core compatible with PHP 8.3 Active . Contrib world is a bit different, but I suppose most of the D7 TOP modules will make this until EOL as well (as there was not many changes in PHP 8.3).

πŸ‡ΈπŸ‡°Slovakia poker10

It is not difficult to solve this. But all core issues need to meet some requirements to be able to be committed. For example there are core gates β†’ all issues should pass before commit, then there is an issue etiquette β†’ and so on.

So for example we cannot commit an issue without the summary, because that field serves the purpose that all contributors and committers will have a summary at hand and does not need to read all comments to see what is the purpose of the issue (what is a problem, what is the proposed solution, ...). It is also important in case we would need to return back here in case the commit will cause some side effects, etc. All these rules are in place to guarantee the quality of all contributions to the Drupal core.

I think the first step to update issue summary is relatively easy. Then there are steps to reproduce - thanks for the PDF documentation and explanation. To create a test for this patch it would help, if someone can write steps to reproduce in a way similar to this:

  1. install Drupal 7.99
  2. enable module X,Y,Z
  3. add a field X
  4. go to node edit and see the notice/warning/..
  5. ...

Then we will be able to create a test and move it forward. Currently I was unable to simulate the problem, so probably there is some custom code or contrib module needed to get this notice/warning.

Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

Hm, coud this be a problem with CORE_LEG_STABLE variable not updated?

CORE_LEG_STABLE:
        value: "7.98"

I have created an issue for updating this: #3408757: Update CORE_LEG_STABLE to 7.99 β†’

Maybe we can then try to revert this change if this was a problem? So we know for future updates.

πŸ‡ΈπŸ‡°Slovakia poker10

PHP 8.0 went EOL, do not recomment it + minor text updates.

πŸ‡ΈπŸ‡°Slovakia poker10

There are usages in core where upload_validators are used with the type file. For example in Drupal\system\Form\ThemeSettingsForm, see: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/syste...

      $form['logo']['settings']['logo_upload'] = [
        '#type' => 'file',
        '#title' => $this->t('Upload logo image'),
        '#description' => $this->t("If you don't have direct file access to the server, use this field to upload your logo."),
        '#upload_validators' => [
          'FileIsImage' => [],
        ],
      ];

Based on this I think it is possible to use upload_validators on type file as well.

πŸ‡ΈπŸ‡°Slovakia poker10

The D7 patch still applies and it is the same as the D10 code, see: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/updat... .

However, the test-only patch for D7 does not fail (see #49). So either this is no longer a problem in D7, or something has changed and we need a different approach in the test. Moving to Needs Work (I am not creating a separate D7 issue yet, because it is possible this is no longer an issue in D7 and we can close this).

πŸ‡ΈπŸ‡°Slovakia poker10

We probably need to test this on D7 before making this change to production.

πŸ‡ΈπŸ‡°Slovakia poker10

My points seems to be resolved, so moving back to RTBC. Thanks.

πŸ‡ΈπŸ‡°Slovakia poker10

There seems to be other non-silenced deprecation message, for example Drupal\Component\Assertion\Handle:

trigger_error(__NAMESPACE__ . '\Handle is deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Instead, use assert_options(ASSERT_EXCEPTION, TRUE). See https://www.drupal.org/node/3105918', E_USER_DEPRECATED);

Wouldn't it be better to expand the scope to search/fix also others, if there are any left? Or is it OK to fix just this one? Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

I have reviewed the MR and left one comment which is probably still not resolved from previous threads.

And also one additional minor comment.

Otherwise I think this looks good!

πŸ‡ΈπŸ‡°Slovakia poker10

I have added tags to the issue in my previous comment, which should be the next steps if we want to move this forward. Issue summary is empty - it needs to be updated according to the template and together with the steps to reproduce the problem. Then we need to create a test for this. Then we can review the issue and consider if we can commit this. Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

Seems like there is already an issue for this: #3317273: Set up a Drupal.org GitLab issues bot β†’

I think that contributors should be able to do most of changes they are allowed to do on Drupal.org currently. This includes changing labels, etc. Unless of course we want to completely change the workflow for contributors and add more work for people with extra permissions, which I think we probably don't (but it is my personal opinion).

So something like we @mention a bot in the comment with some labels and bot will add these to the issue. And so on. Currently I do not have full picture what else could be needed (especially for core), but I think this will be discussed further in the referenced issue.

πŸ‡ΈπŸ‡°Slovakia poker10

According to the recent Slack discussion adding a note that we probably would need to setup a Gitlab bot to allow making changes to status labels by contributors (similar to what is possible now). Otherwise only maintainers + developers would be able to to that and it could create a lot of work for something contributors used to do. Maybe we will need a follow-up issue for this?

πŸ‡ΈπŸ‡°Slovakia poker10

Updated release schedule.

πŸ‡ΈπŸ‡°Slovakia poker10

I do not think we could easily change this for reasons mentioned in #35 and #12. Changing this will break existing sites already using this feature. So if we want to do this, we should think about existing sites and BC.

On the other hand, I do not think this issue is critical enough, so I suppose it should remain as Postponed, see #42. I see some progress in child issues here: 🌱 [Meta] Tasks to deprecate Book module Active . Thanks!

πŸ‡ΈπŸ‡°Slovakia poker10

Drupal 7.99 was released yesterday: https://www.drupal.org/project/drupal/releases/7.99 β†’

Thanks everyone who contributed!

I have created a new meta issue for the next release scheduled for 2024-06-05: πŸ“Œ [meta] Priorities for 2024-06-05 release of Drupal 7 Active and carried over all open issues from this meta issue.

πŸ‡ΈπŸ‡°Slovakia poker10

Can you please provide steps to reproduce this on clean Drupal 7 installation? I think this could be caused by some code/contrib module/theme which changed the default theme registry callback.

Or if possible, can you verify what the _theme_registry_callback(); function returns? Thanks.

πŸ‡ΈπŸ‡°Slovakia poker10

Other services were changed here #2341701: Provide an abstract logger.channel declaration β†’ , which was when issue about adding new logger.channel.file was in progress here #2050759: Move drupal_chmod and other code in file.inc to a Drupal\Core\File\FileSystem class β†’ . The later issue was just rerolled after these changes, so it is probably just an oversight. I have not found a discussion about the format in the referenced issue.

πŸ‡ΈπŸ‡°Slovakia poker10

Require PHP 8.3 for Drupal 11.

+1 for this proposal. I already mentioned that PHP support on shared hostings tends to be quite flexible, so even if sites are not running containers, this version should not make extra problems in 2024 (or 2025). And it will have a benefit for migration between D10 and D11 as well.

Production build https://api.contrib.social 0.61.6-2-g546bc20