I think this will be up to Experience Builder. Let's move it back to Starshot if Experience builder is not the answer :)
Not related to the new content of the parent anymore
#3447749: Added the optional ability to apply recipes from the core installer UI → is part of this I think. I think the Project Browser part will need to be resolved in Project Browser :D
BTW while I moved this to the Starshot project, I think it would be ultimately solved in Project Browser and Starshot itself would only need to modify the installer flow to inject the Project Browser experience. So the main solution I think for this will lie in Project Browser, something like these items
- A way is needed to tell which component recipes should be offered here, initial MVP could be hardcoded
- A simplified UI should be built that offers those recipes and installs them when you continue on this screen
Moving this to the Starshot project. I don't think core can provide a solution for this before Starshot and Starshot needs it fast :D
I also don't know the value in putting it during install, since I think a lot of infrastructure needs to be installed to allow recipes to work, I wonder if it's technically an interstitial between install and visiting the site.
I think it's a small distinction but important.
Yeah I think when we are talking about "Installation" we mean exactly this interstitial, where you can add more stuff after the basics are installed, before you go to your site. @catch put in lots of work to make Drupal install-less but hit lots of problems. His concept for doing project browser / recipe installation in the installer was also to add it at the end of the installer, when the infrastructure is all built up.
I think the MVP of Starshot may be that there is no vertical selector (Magazine site, Community site site, etc) at the start of Starshot but one CMS recipe is installed (you already did the persona selection on the d.o page where you picked CMS over core framework). But the additional recipes would show in the Starshot UI as a simplified Project browser UI.
I think we are talking about this UI screen:
Yeah I am not surprised as that is what this part of the diff would do (the drupal_root key is already added a bit above). The str_replace above this needs to be differently done, I think the drupal part removed from that, then this can add the root.
diff --git a/src/DeprecationAnalyzer.php b/src/DeprecationAnalyzer.php
index 56affa470c5b0922be0cd9d3522b04c2a63abb63..41026bdd28815493d862b9f98a9a6aa710a49ef6 100644
--- a/src/DeprecationAnalyzer.php
+++ b/src/DeprecationAnalyzer.php
@@ -548,6 +548,11 @@ final class DeprecationAnalyzer {
"\tdrupal:\n\t\tdrupal_root: '" . DRUPAL_ROOT . "'",
$config
);
+ $config = str_replace(
+ "\tdrupal:",
+ "\tdrupal:\n\t\tdrupal_root: '" . DRUPAL_ROOT . "'",
+ $config
+ );I don't think creating the Starshot governance under the Technical Working Group is the way to go. While it has been historically hard to change governance indeed, and that was the best way to do for coding standards, Starshot is not supposed to be lead from a technical standpoint but rather a user needs / product standpoint, so I think it needs to be set up differently, not just for the sake of paperwork but also perception. Dries pledged his focus on this project, so I don't think it will be a problem to set up whatever governance structure needed so long as the right kind of people are there.
I asked the promote Drupal folks for source files for the logo. I don't think the font applies to core unless the current typo is used.
Gábor Hojtsy → created an issue.
Update Drupal 10.3 and 11 dates to current understanding. Update 11.1 to be in line with 10.4 dates.
Wrote this quick FAQ to begin with and published at https://drupal.org/starshot#faq, suggestions welcome:
Is Starshot a fork of Drupal?
No. Starshot will be based on the strong foundation of Drupal core, relying on Project Browser and Recipes to achieve a great out-of-the-box experience. It will enable people without Drupal experience to easily create a new Drupal site and extend it with pre-packaged recipes, all using their browser.
Is Starshot a rewrite of Drupal?
No. Starshot will be based on the strong foundation of Drupal core, relying on Project Browser and Recipes to achieve a great out-of-the-box experience. It will enable people without Drupal experience to easily create a new Drupal site and extend it with pre-packaged recipes, all using their browser.
Is Starshot a distribution (or install profile) of Drupal?
No. Starshot is based on Recipes (see below), which are a lot more flexible than distributions.
What are Recipes?
Recipes are supported by new APIs in Drupal 10.3 and 11.0. Recipes are automated site builder steps. In technical terms a combination of preconfigured Drupal extensions. Recipes can depend on other recipes, they are composable with other recipes and unlike distributions, do not lock the site in. The eventual goal is that Drupal core itself will offer up recipes instead of install profiles.
Is Starshot the product name?
No. The initiative is called Starshot. There is no intention to launch an entirely new brand. The working name for the eventual product is Drupal CMS, but that may still change.
What happens to Drupal core?
Drupal core is a strong, stable basis for Starshot. For the time being Starshot plans to build on Automated updates/Package manager, Project Browser and Recipes additionally to core. The ideal end state is that Drupal core becomes capable to launch Recipes for starter experiences and then be able to apply further recipes on top. Drupal core is not going away.
Gábor Hojtsy → created an issue.
Definitely more info should be available, but it was a big reveal and we did not have that part done yet. In hindsight we should have had plans for an FAQ, etc. But we now know a lot of the common questions we are getting at DrupalCon and can build an FAQ based on that.
Its a double edged sword as well. Some people had the feedback that this felt too baked and too decided (as opposed to the longer timeline projects Dries usually announced before, where he only outlined an idea and it was done over years), while many others said this is too half baked and why don't we know a lot more. @cmlara you are in the later camp, but not everyone is :)
Current information is available at drupal.org/starshot and also https://dri.es/state-of-drupal-presentation-may-2024
Published the draft CR at https://www.drupal.org/node/3445169 →
hestenet → credited Gábor Hojtsy → .
The 11.x branch is "main", so its the latest dev version. 11.2.x will be branched from there, etc. See https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... →
What fails currently without this?
Opened 📌 MariaDB is deprecating tx_isolation in 11.1.1 Active .
Gábor Hojtsy → created an issue.
Looks good, did not spot any mistakes reviewing the code. Also the green tests are reassuring :)
Ah I found 📌 Add testing wtih SQLite 3.45 Fixed updated sqlite and PostgreSQL version requirement did not change. All right.
BTW https://git.drupalcode.org/project/drupal/-/commit/10466dba9d7322ed55165... already raised the requirement to 3.45 two weeks ago and that has been released in alpha1. I think if there are really good reasons, we can roll this back, but I agree sqlite is mainly used for testing locally.
Anecdotally my homebrew based PHP setup on Mac is PHP 8.3.6 currently with sqlite 3.45.3, and this is the default I got when I asked homebrew to install/update PHP.
The MR updates the docs on SQLite and Postgres but does not seem to make code changes for those? Is that correct?
Gábor Hojtsy → created an issue.
It is not needed immediately I think. I will showcase this in my DrupalCon session next week and plan to blog about it some way. If we are still finalizing where it would end up, I can postpone that blog post, no biggie. I expect this to help with getting some projects maintain a forwards compatible codebase on an ongoing basis. It would alert maintainers in scheduled jobs if it becomes incompatible due to new deprecations and it would help review MRs with automated deprecated API checks so humans don't need to. I think that could be a big win.
Although I worked on this, this is super simple, so will go ahead and RTBC it. The new dates are all in https://www.php.net/supported-versions.php and were adjusted to end of years.
The d10 branch/MR needs to be fixed up or redone. I don't currently have time to do that so help is welcome :)
https://www.php.net/supported-versions.php happened so this should go into core now.
jjchinquist → credited Gábor Hojtsy → .
Gábor Hojtsy → created an issue.
Gábor Hojtsy → created an issue.
I think its fine that there is not a meta-test, the newly deprecated state keys will test the infrastructure too again.
Looks good, I don't see any issue and its tested in the MR with upgrade status analysis extending it as well :)
Trying this out now on 📌 Test code quality analysis integration of Upgrade Status Active .
Gábor Hojtsy → created an issue.
Woot, thanks!
This also removed the deprecation infrastructure in state. Do we believe that is not needed anymore? I proposed above to only remove the array key which defined the once key that was deprecated not the whole method of deprecating state.
lauriii → credited Gábor Hojtsy → .
Sorry for being that guy. But my main problem remains with the text that it does not help. The logic I think is "the values may be overridden elsewhere (we don't know where) based on some criteria (which we also don't know)" so users may or may not encounter that override anywhere else. I can see this may still help solve some confusion when/if you are aware of those overrides or conditions. But I also see a lot of potential for new confusion too. Because the override is not present in the form itself. So the statement that the values are overridden is not true for the form itself and may only happen elsewhere.
Eg. you see your site name is "Bla". You go edit it and its "Foo" there. You demand an explanation. But you go edit a setting and it says its overridden, but you may have never seen the overriden value (in some organic group or whatnot) and you are puzzled as to what does that even mean.
Looks good on lib/Session. It does not yet include lib/State. I think we should only remove the defined array element in lib/State and keep the infrastructure as-is. (That said the key does not say there it is deprecated for 11, so we need to verify that).
This failed on the following so sent for a retest.
Drupal\Tests\migrate\Unit\MigrationTest::testMigrationDependenciesInConstructor
with data set "invalid key" (array(array()))
This test did not perform any assertionsThat said the code removed says it should be replaced with a PHP error fired?
Looks generally good. Why do we keep TestSuiteBaseTest?
Aw, such a perfect update! Thanks for being so thorough! I would love to get this and give it some publicity. How would someone go about integrating this into their drupal.org modules's CI workflow and optionally if they have their own gitlab (or github) CI setup, how would this be possible to integrate there?
nicoloye → credited Gábor Hojtsy → .
If Adaptive theme does not have colors in core's update status and core's status report page, then that is a design choice in Adaptive theme :) The new upgrade status module uses standard core classes to rely on design choices in admin themes, which makes it possible to be compatible with light and dark modes, configurable hues, etc. in some themes. Forcing specific colors make it impossible to support that.
Gábor Hojtsy → created an issue.
Test coverage for this is easy because we had 7 empty PHP files to work around this in the tests :D
Re the suggestion above to not run PHPStan if there were no files, I think unless its expensive to run it, I would not avoid it. Otherwise we would need to maintain yet another list of possible PHP extensions to process in Upgrade Status, that is already built into phpstan-drupal. So I think this is fine to recognize it at the end of the result.
Proposed a solution that processes this at the IMHO right place.
Gábor Hojtsy → created an issue.
Even after the core module removals, this 97 mentions of @deprecated against Drupal 11 (and in two cases Drupal 10) remains. I think most bigger ones have issues above, but not all, in case someone wants to chip away at this :) (The list of E_USER_DEPRECATED is much longer, probably lots of these will remove many of that too).
core/misc/ajax.js: * @deprecated in drupal:8.6.0 and is removed from drupal:10.0.0.
core/misc/ajax.js: * @deprecated in drupal:8.6.0 and is removed from drupal:10.0.0.
core/tests/Drupal/Tests/RandomGeneratorTrait.php: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0.
core/tests/TestSuites/TestSuiteBase.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. There is no
core/tests/TestSuites/KernelTestSuite.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. There is no
core/tests/TestSuites/FunctionalJavascriptTestSuite.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. There is no
core/tests/TestSuites/BuildTestSuite.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. There is no
core/tests/TestSuites/UnitTestSuite.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. There is no
core/tests/TestSuites/FunctionalTestSuite.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. There is no
core/includes/bootstrap.inc: * @deprecated in drupal:8.3.0 and is removed from drupal:11.0.0.
core/lib/Drupal/Core/Password/PhpassHashedPassword.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. The
core/lib/Drupal/Core/Logger/LoggerChannelFactory.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Asset/AssetCollectionOptimizerInterface.php: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. There is
core/lib/Drupal/Core/Test/TestSetupTrait.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. There is no
core/lib/Drupal/Core/Config/ConfigEvents.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Config/TypedConfigManager.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Config/TypedConfigManager.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Config/TypedConfigManager.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Config/TypedConfigManager.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Datetime/Element/Datetime.php: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0.
core/lib/Drupal/Core/Entity/Controller/EntityViewController.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Entity/EntityStorageInterface.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Entity/EntityStorageInterface.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Entity/EntityTypeManager.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0.
core/lib/Drupal/Core/Render/Element/Ajax.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Return an
core/lib/Drupal/Core/Render/MetadataBubblingUrlGenerator.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Only string
core/lib/Drupal/Core/Render/MetadataBubblingUrlGenerator.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Updater/Module.php: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Controller/ArgumentResolver/Psr7RequestValueResolver.php: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0.
core/lib/Drupal/Core/Controller/ArgumentResolver/RouteMatchValueResolver.php: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0.
core/lib/Drupal/Core/Url.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. There is no
core/lib/Drupal/Core/Url.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. There is no
core/lib/Drupal/Core/Routing/UrlGenerator.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Only string
core/lib/Drupal/Core/Routing/UrlGenerator.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Utility/LinkGeneratorInterface.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use
core/lib/Drupal/Core/Session/PermissionsHashGenerator.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. There is no
core/modules/update/src/Controller/UpdateController.php: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use
core/modules/jsonapi/src/Controller/TemporaryJsonapiFileFieldUploader.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/jsonapi/src/Controller/TemporaryJsonapiFileFieldUploader.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/jsonapi/src/Controller/TemporaryJsonapiFileFieldUploader.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/jsonapi/src/Controller/TemporaryJsonapiFileFieldUploader.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/file/file.api.php: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use the
core/modules/file/file.module: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use the
core/modules/file/file.module: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use the
core/modules/file/file.module: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use the
core/modules/file/file.module: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use the
core/modules/file/file.module: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use the
core/modules/file/file.module: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use the
core/modules/file/file.module: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/file/file.module: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/file/file.module: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/file/src/Plugin/rest/resource/FileUploadResource.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/file/src/Plugin/rest/resource/FileUploadResource.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/file/src/Plugin/rest/resource/FileUploadResource.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/file/src/Plugin/rest/resource/FileUploadResource.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/file/src/Upload/UploadedFileInterface.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/file/src/Upload/UploadedFileInterface.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/file/src/Upload/UploadedFileInterface.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/file/src/Upload/FileUploadHandler.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0.
core/modules/contextual/js/contextual.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is no
core/modules/contextual/js/contextual.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is no
core/modules/contextual/js/contextual.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is no
core/modules/contextual/js/toolbar/models/StateModel.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is no
core/modules/contextual/js/toolbar/views/AuralView.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is no
core/modules/contextual/js/toolbar/views/VisualView.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is no
core/modules/contextual/js/models/StateModel.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is no
core/modules/contextual/js/contextual.toolbar.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is
core/modules/contextual/js/views/KeyboardView.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is no
core/modules/contextual/js/views/AuralView.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is no
core/modules/contextual/js/views/RegionView.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is no
core/modules/contextual/js/views/VisualView.js: * @deprecated in drupal:9.4.0 and is removed from drupal:11.0.0. There is no
core/modules/user/user.module: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. There is no
core/modules/user/user.module: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. There is no
core/modules/user/user.module: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use
core/modules/user/user.module: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use
core/modules/user/src/Form/UserLoginForm.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. There is no replacement.
core/modules/workspaces/src/Form/WorkspaceFormInterface.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/workspaces/src/WorkspaceManagerInterface.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/workspaces/src/WorkspaceManagerInterface.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/workspaces/src/WorkspaceManagerInterface.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. There is no
core/modules/workspaces/src/WorkspaceAssociationInterface.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use the
core/modules/field/tests/src/Traits/EntityReferenceTestTrait.php: * @deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use
core/modules/system/system.install: // @deprecated The sequences table has been deprecated in drupal:10.2.0 and is
core/modules/system/tests/modules/deprecation_test/deprecation_test.module: * @deprecated in drupal:8.4.0 and is removed from drupal:9.0.0. This is
core/modules/migrate/src/Plugin/migrate/id_map/Sql.php: * @deprecated in drupal:9.5.0 and is removed from drupal:11.0.0. Use
core/modules/migrate/src/Plugin/MigrationInterface.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. There is no
core/modules/migrate/src/Plugin/MigrationInterface.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. There is no
core/modules/migrate/src/Plugin/MigrationInterface.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. There is no
core/modules/migrate/src/Plugin/Migration.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. There is no
core/modules/path_alias/src/AliasManager.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. Use
core/modules/taxonomy/src/Plugin/views/argument/Taxonomy.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. There is no
core/modules/taxonomy/src/Plugin/views/argument/IndexTidDepth.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0. There is no
core/modules/book/tests/src/Functional/BookTestTrait.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use
core/modules/ckeditor5/src/Controller/CKEditor5ImageController.php: * @deprecated in drupal:10.3.0 and is removed from drupal:11.0.0 without replacement.
core/modules/views/js/ajax_view.js: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0.
core/modules/views/src/Entity/Render/EntityTranslationRenderTrait.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use
core/modules/views/src/Ajax/ScrollTopCommand.php: * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0.I'm surprised Adaptive theme does not have the standard colors. These are used on the update status (core built in) page as well as site status report. Are those colorless also?
I see how this improved our stability and made our life less complicated. I also think its a far fetched idea that Drupal 10.x users would update to 12.x in place, that would require all of their contribs to somehow support that update too. So we don't need to bend over backwards to support that. Let's consider this policy agreed and refine the update functions if/when we have feasibly backportable solutions.
I'm a bit torn on this. First, it is completely valid that no PHP code may be found in an extension. It may be only configuration and composer files shipped in an extension for example. At the same time if there were no PHP files found but they should have been, then that is an error we should report.
That said, it is probably safer to not display this as an error or at least turn it into a warning that integrates well into the UI rather than an error dump like it is now.
For that to happen, we do need to post-process the results, so I think that is a logical direction. However that parsing should not happen on the Drush command level like in the MR but rather where the phpstan error results are stored or processed for being stored.
Which admin theme are you using? How does it look like if you switch your admin theme to something else, eg. Claro? The module now uses standard core classes which have assigned colors in Claro and other admin themes such as Gin. Instead of specifying our own colors which may or may not match with the theme. See https://www.hojtsy.hu/blog/2024-apr-18/new-upgrade-status-420-beautiful-... for more background.
Gábor Hojtsy → made their first commit to this issue’s fork.
Gábor Hojtsy → created an issue.
Gábor Hojtsy → created an issue.
Was looking into adding a test on 3rd party deprecations triggered from Twig compile but at least the trigger for this issue in 🐛 condition_info_alter deprecation triggers false possitive deprecation notices Fixed was resolved by removing the deprecation notice there and it was erroneously triggered widely :D Either way those could still show up with this, and the tests already prove that there is no regression. Also we gained a new feature of syntax errors reported from Twig compilation, which is good IMHO.
Fails were due to the newly introduced catching of twig syntax errors.
This way we can keep reporting Twig level errors when they are twig level (like we do now) and we can also report the runtime errors found while parsing the twig file with their PHP file/line source information that are currently leading to the fails.
So we are using https://github.com/twigphp/Twig/blob/3.x/src/Util/DeprecationCollector.php to collect the Twig deprecation errors. All that does is it sets its own error handler and collects all deprecation errors reported while compiling the Twig templates. It does not collect the file name and line number for the error messages though. I think we should subclass that and in case the error message does not come with a twig file name and line number, we should include the file name and line number from set_error_handler() that is currently not saved.
public function collect(\Traversable $iterator): array
{
$deprecations = [];
set_error_handler(function ($type, $msg) use (&$deprecations) {
if (\E_USER_DEPRECATED === $type) {
$deprecations[] = $msg;
}
});
foreach ($iterator as $name => $contents) {
try {
$this->twig->parse($this->twig->tokenize(new Source($contents, $name)));
} catch (SyntaxError $e) {
// ignore templates containing syntax errors
}
}
restore_error_handler();
return $deprecations;
}
This may also be useful in the future for PHP 8.3 in case of Drupal 11 for example.
Found the message on dev.acquia.com thankfully so could add in https://git.drupalcode.org/project/deprecation_status/-/commit/adc9ec180...
Added the two related messages to https://git.drupalcode.org/project/deprecation_status/-/commit/adc9ec180..., thankfully I found them in the active deprecation list on dev.acquia.com.
Fixed anyway in https://git.drupalcode.org/project/deprecation_status/-/commit/adc9ec180... for now
Committed in https://git.drupalcode.org/project/deprecation_status/-/commit/adc9ec180... anyway for now.
Fixed this in a commit to add module_load_include() and friends:
https://git.drupalcode.org/project/deprecation_status/-/commit/adc9ec180...
Followup to add expected message of module_load_install() manually:
https://git.drupalcode.org/project/deprecation_status/-/commit/b7a12ae57...
Duh, looks like we modify that to make unified:
$error_string = preg_replace('!(u|U)se \\\\Drupal!', '\1se Drupal', $error_string);
So yeah the listing is wrong, and it needs to be without the backslash.
Fixed that in https://git.drupalcode.org/project/deprecation_status/-/commit/b7a12ae57...
Updated as part of this commit: https://git.drupalcode.org/project/deprecation_status/-/commit/adc9ec180...
Committed as part of this https://git.drupalcode.org/project/deprecation_status/-/commit/adc9ec180...
Ah the coverage list has \Drupal but the error you cited above does not have the backslash before Drupal. Messages are not consistent in this. I can't find a contrib that has this, so went to check Drupal 9.5.x: https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/modules/user... That also has \Drupal in both the @deprecated and in the trigger_error(), so looks like our coverage information is correct in deprecation_status?
Is there something wrong in deprecation_status?
https://git.drupalcode.org/project/deprecation_status/-/commit/ee41b88d2... is the original commit that already has it.
This was already part of the "modern" script I committed in June 2022. The deprecation itself was updated from Drupal 10 to 11, so that is why it is not matched.
Hm, we have this in our coverage list since August 15, 2022: https://git.drupalcode.org/project/deprecation_status/-/commit/1ab775092...
Is there something wrong with this?
Did not find any contrib results in https://dev.acquia.com/drupal11/deprecation_status/errors?error=%2ARoute.... But found one instance at https://dev.acquia.com/drupal10/deprecation_status/errors?error=%2ARoute...
Based on that I think the covered deprecations are these:
'Symfony\Cmf\Component\Routing\RouteObjectInterface::ROUTE_OBJECT is deprecated and removed in Drupal 10. Use Drupal\Core\Routing\RouteObjectInterface::ROUTE_OBJECT instead.',
'Symfony\Cmf\Component\Routing\RouteObjectInterface::ROUTE_NAME is deprecated and removed in Drupal 10. Use Drupal\Core\Routing\RouteObjectInterface::ROUTE_NAME instead.',
'Symfony\Cmf\Component\Routing\RouteObjectInterface::CONTROLLER_NAME is deprecated and removed in Drupal 10. Use Drupal\Core\Routing\RouteObjectInterface::CONTROLLER_NAME instead.',
The same rector fix included rules for module_load_install(), but I did not find a message for that at https://dev.acquia.com/drupal11/deprecation_status/errors?error=%2Amodul... I'm surprised it is not used in contrib?! Could it be that the bot already fixed them?
Thanks for posting the exact deprecation message. I did not find it in https://dev.acquia.com/drupal11/deprecation_status/errors?error=%2AtoInt%2A -- could it be that the bot successfully fixed it in contrib by now?
Thanks for posting the exact deprecation message. I did not find it in https://dev.acquia.com/drupal11/deprecation_status/errors?error=%2AFILE_... -- could it be that the bot successfully fixed it in contrib by now?
jjchinquist → credited Gábor Hojtsy → .
Added a brief release note snippet. I am not aware of things users need to do in order to "move" to the stable module, if they are already using workspaces.
@larowlan: Drupal core already has an automated system to drop support for PHP versions that go unsupported. Symfony 7.4 goes to the end of 2029 (https://symfony.com/releases/7.4) while even with an extended PHP 8.3 support, that would only go near the end of 2027.
I am hopeful the performance improvements will lead to faster adoption of PHP 8.3. Do the performance improvements require new language constructs though? Lowering the requirement to 8.2 would not mean people can't use PHP 8.3 :)
DrupalCon regularly uses images from the Flickr pools of previous events as submitters were encouraged to share those under CC licenses. So there must be lots of images to source from there of people working on Drupal, discussing things, etc.
Interesting, this links to https://wiki.php.net/rfc/release_cycle_update but that says it has a date of 2024-03-21. May be the date for the 2.0 version.
Based on packagist data on PHP version usage, PHP 8.3 adoption was only 6.4% in January: https://stitcher.io/blog/php-version-stats-january-2024. While PHP 8.3 shot off much faster than 8.2 did, it still lags behind the speed of adoption of PHP 8.1 and that took more than a year to get to roughly 35% of adoption.
I think we have our own struggles with getting people on new major versions, making it this much harder by requiring the bleeding edge version for a couple minor (feature) releases when there is no more features on the older major sounds quite ambitious.
Am I reading the data wrong? I actually proposed 📌 Lower PHP requirement from 8.3 to 8.2 in Drupal 11 due to increased security support Closed: won't fix .