Quantcast
Channel: Issues for Drupal core
Viewing all 295277 articles
Browse latest View live

[≈Nov. 11] Fix Drupal.Commenting.Deprecated coding standard

$
0
0

Problem/Motivation

Following from #2908391: Add a rule for expected format of @deprecated and @trigger_error() text we need to fix core to adhere to the two new coding standards.

This issue will fix the @deprecated doc tag to adhere to the main Deprecated.IncorrectTextLayout standard. Follow-up issues will fix the version formats, missing @see tag and missing extra-info.

Proposed resolution

Do an automated conversion with a work-in-progress PHPCS fixer (see #3057988: Automatically fixing @deprecated doc text). This creates quite a huge patch and we want to commit this as a first chunk to make reviewing easier.

Remaining tasks

  1. Commit the first huge automated conversion chunk
  2. Follow-up with patches to fix the rest (manually)
  3. Enable the new Drupal.Commenting.Deprecated in phpcs.xml

See #3094454: Fix remaining @Deprecated layout manually and enable the coding standard for stesp 2 and 3.


Process to check and fix this coding standard

Step 1: Preparation

Open the file core/phpcs.xml.dist and add a line for the sniff of this ticket. The sniff name is in the issue title. Make sure your patch will include the addition of this line.

Step 2: Install & configure PHPCS

Install PHP CodeSniffer and the ruleset from the Coder module:

$ composer install
$ ./vendor/bin/phpcs --config-set installed_paths ../../drupal/coder/coder_sniffer

Once you have installed the phpcs package, you can list all the sniffs available to you like this:

$ ./vendor/bin/phpcs --standard=Drupal -e

This will give you a big list of sniffs, and the Drupal-based ones should be present.

Step 3: Prepare the phpcs.xml file

To speed up the testing you should make a copy of the file phpcs.xml.dist (in the core/ folder) and save it as phpcs.xml. This is the configuration file for PHP CodeSniffer.

We only want this phpcs.xml file to specify the sniff we're interested in. So we need to remove all the rule items, and add only our own sniff's rule. Rule items look like this:

<rule ref="Drupal.Commenting.Deprecated"/>

Remove all of them, and add only the sniff from this issue title. This will make sure that our tests run quickly, and are not going to contain any output from unrelated sniffs.

Step 4: Run the test

Now you are ready to run the test! From within the core/ folder, run the following command to launch the test:

$ cd core/
$ ../vendor/bin/phpcs -p

This takes a couple of minutes. The -p flag shows the progress, so you have a bunch of nice dots to look at while it is running.

Step 5: Fix the failures

When the test is complete it will present you a list of all the files that contain violations of your sniff, and the line numbers where the violations occur. You could fix all of these manually, but thankfully phpcbf can fix many of them. You can call phpcbf like this:

$ ../vendor/bin/phpcbf

This will fix the errors in place. You can then make a diff of the changes using git. You can also re-run the test with phpcs and determine if that fixed all of them.


Fix remaining @Deprecated layout manually and enable the coding standard

$
0
0

Problem/Motivation

This is a follow-on from #3048498: [≈Nov. 11] Fix Drupal.Commenting.Deprecated coding standard where the automated patch fixed 653 of the 675 @deprecated messages reported under the Drupal.Commenting.Deprecated.IncorrectTextLayout sniff.

Remaining tasks

  1. Commit the first huge automated conversion chunk
  2. Follow-up with patches to fix the rest (manually)
  3. Enable the new Drupal.Commenting.Deprecated in phpcs.xml

Add "no_ui = true" to the definition of deprecated action plugins

$
0
0

Problem/Motivation

In the Feeds module I expose action plugins in the UI and I do that in the following way:
$action_definitions = \Drupal::service('plugin.manager.action')->getDefinitionsByType($entity_type);
The issue is that also deprecated action plugins show up in the UI, without the user knowing. The action plugins only conditionally get instantiated and that happens at a totally different level (not in the admin UI).

Some of the deprecated action plugins are documented on https://www.drupal.org/node/2919303, but in the definitions of these you cannot see that they are deprecated:

node_publish_action’ => array(6)
    ‘confirm_form_route_name’ => string(0) “”
    ‘type’ => string(4) “node”
    ‘id’ => string(19) “node_publish_action”
    →‘label’ => Drupal\Core\StringTranslation\TranslatableMarkup(5)
    ‘class’ => string(37) “Drupal\node\Plugin\Action\PublishNode”
    ‘provider’ => string(4) “node”

Related Feeds issue #3094433: Hide deprecated actions from UI (and replace them with a database update)

Proposed resolution

@andypost pointed me to the following documentation: https://www.drupal.org/core/deprecation#how-plugin

Add no_ui = true to the plugin definition. If the plugin does not support no_ui but is selectable in a UI then an issue will be needed to add it.

However I see also some discussion on #2922451: [policy no patch] Make it possible to mark plugins as deprecated that the no_ui key won't cover plugins that are extending deprecated action plugins. But I think having at least the ones in Drupal Core not showing up in the UI would already be a great win.

Remaining tasks

  • Add $no_ui to the plugin definition
  • Set a no_ui key for every deprecated action plugin.

User interface changes

The deprecated action plugins in Drupal Core no longer show up in the UI when developers iterating over action plugins check for the no_ui key.

API changes

The action plugin definition get a new property called $no_ui.

Data model changes

None.

I'll work on a patch.

[meta] Core should not trigger deprecated code except in tests and during updates

$
0
0

Problem/Motivation

#2870194: Ensure that process-isolated tests can use Symfony's PHPunit bridge to catch usages of deprecated code added the ability to test deprecated code. In order to get that done we add to add \Drupal\Tests\Listeners\DeprecationListenerTrait::getSkippedDeprecations() because core is exercising lots of deprecated code. This is all technical debt that we need to clear up. This issue is going to coordinate all the issues that need to be filed in order to stop using deprecated code.

The @todo list:

DONE:

Proposed resolution

Ensure each skipped deprecation has an issue to work on.

Remaining tasks

Create all the necessary issues

User interface changes

None

API changes

None

Data model changes

None

Fully deprecate WorkflowDeleteAccessCheck

$
0
0

Problem/Motivation

This is a child issue of #2856744: [META] Add trigger_error(..., E_USER_DEPRECATED) to deprecated code

Drupal\workflows\WorkflowDeleteAccessCheck is marked as @deprecated and @internal.

It's also a service in workflows.services.yml. The service is named workflows.access_check.delete_state.

The only place in core that makes reference to this deprecated service or its class name is core/modules/content_moderation/tests/fixtures/update/drupal-8.4.0-content_moderation_installed.php.

Adding a typical @trigger_error() to WorkflowDeleteAccessCheck fails quite a few tests: https://www.drupal.org/pift-ci-job/1106392 (Search for 'WorkflowDeleteAccessCheck' on the page).

Proposed resolution

Figure out how to trigger a deprecation error from this service so that developers will avoid using it.

Either mark tests using that fixture as @group legacy or rebuild the fixture in some way.

Remaining tasks

User interface changes

API changes

Data model changes

Rename Action module to Action UI in the UI and in comments

Error: Call to a member function getLabel() after enable layout_builder

$
0
0

Existing drupal 8 site (upgraded from 8.2.x to 8.3, 8.4, 8.5). Current version 8.5.5 . If I enable layout_builder, then:

Error: Call to a member function getLabel() on null in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions() (line 111 of /home/agwophqf/public_html/core/modules/layout_builder/src/Plugin/Derivative/FieldBlockDeriver.php) #0 /home/agwophqf/public_html/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(101): Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions(Array) #1 /home/agwophqf/public_html/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(87): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array) #2 /home/agwophqf/public_html/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(284): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions() #3 /home/agwophqf/public_html/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(175): Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() #4 /home/agwophqf/public_html/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php(22): Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() #5 /home/agwophqf/public_html/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php(16): Drupal\Core\Plugin\DefaultPluginManager->getDefinition('system_main_blo...') #6 /home/agwophqf/public_html/core/lib/Drupal/Component/Plugin/PluginManagerBase.php(76): Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('system_main_blo...', Array) #7 /home/agwophqf/public_html/core/lib/Drupal/Core/Plugin/DefaultSingleLazyPluginCollection.php(62): Drupal\Component\Plugin\PluginManagerBase->createInstance('system_main_blo...', Array) #8 /home/agwophqf/public_html/core/modules/block/src/BlockPluginCollection.php(57): Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->initializePlugin('system_main_blo...') #9 /home/agwophqf/public_html/core/lib/Drupal/Component/Plugin/LazyPluginCollection.php(80): Drupal\block\BlockPluginCollection->initializePlugin('system_main_blo...') #10 /home/agwophqf/public_html/core/modules/block/src/BlockPluginCollection.php(45): Drupal\Component\Plugin\LazyPluginCollection->get('system_main_blo...') #11 /home/agwophqf/public_html/core/lib/Drupal/Core/Plugin/DefaultSingleLazyPluginCollection.php(83): Drupal\block\BlockPluginCollection->get('system_main_blo...') #12 /home/agwophqf/public_html/core/lib/Drupal/Core/Plugin/DefaultSingleLazyPluginCollection.php(99): Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->setConfiguration(Array) #13 /home/agwophqf/public_html/core/lib/Drupal/Core/Plugin/DefaultSingleLazyPluginCollection.php(55): Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->addInstanceId('system_main_blo...', Array) #14 /home/agwophqf/public_html/core/modules/block/src/BlockPluginCollection.php(34): Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->__construct(Object(Drupal\Core\Block\BlockManager), 'system_main_blo...', Array) #15 /home/agwophqf/public_html/core/modules/block/src/Entity/Block.php(149): Drupal\block\BlockPluginCollection->__construct(Object(Drupal\Core\Block\BlockManager), 'system_main_blo...', Array, 'bone_content') #16 /home/agwophqf/public_html/core/modules/block/src/Entity/Block.php(138): Drupal\block\Entity\Block->getPluginCollection() #17 /home/agwophqf/public_html/core/modules/block/src/BlockAccessControlHandler.php(113): Drupal\block\Entity\Block->getPlugin() #18 /home/agwophqf/public_html/core/lib/Drupal/Core/Entity/EntityAccessControlHandler.php(105): Drupal\block\BlockAccessControlHandler->checkAccess(Object(Drupal\block\Entity\Block), 'view', Object(Drupal\Core\Session\AccountProxy)) #19 /home/agwophqf/public_html/core/lib/Drupal/Core/Entity/Entity.php(366): Drupal\Core\Entity\EntityAccessControlHandler->access(Object(Drupal\block\Entity\Block), 'view', Object(Drupal\Core\Session\AccountProxy), true) #20 /home/agwophqf/public_html/core/modules/block/src/BlockRepository.php(56): Drupal\Core\Entity\Entity->access('view', NULL, true) #21 /home/agwophqf/public_html/core/modules/block/src/Plugin/DisplayVariant/BlockPageVariant.php(137): Drupal\block\BlockRepository->getVisibleBlocksPerRegion(Array) #22 /home/agwophqf/public_html/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(259): Drupal\block\Plugin\DisplayVariant\BlockPageVariant->build() #23 /home/agwophqf/public_html/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(117): Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch)) #24 /home/agwophqf/public_html/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch)) #25 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #26 /home/agwophqf/public_html/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #27 /home/agwophqf/public_html/vendor/symfony/http-kernel/HttpKernel.php(156): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent)) #28 /home/agwophqf/public_html/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #29 /home/agwophqf/public_html/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #30 /home/agwophqf/public_html/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #31 /home/agwophqf/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #32 /home/agwophqf/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #33 /home/agwophqf/public_html/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #34 /home/agwophqf/public_html/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #35 /home/agwophqf/public_html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #36 /home/agwophqf/public_html/core/lib/Drupal/Core/DrupalKernel.php(666): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #37 /home/agwophqf/public_html/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #38 {main}.

Appending a field item to a field item list doesn't notify the parent of the change

$
0
0

Problem/Motivation

If a non-empty item is appended on a field item list, the parent will not be notified about the change. If you have some listener logic in ContentEntityBase::onChange(), which is expecting to be called for the field on which an item is appended, then this logic will not be triggered at all.

Proposed resolution

Notify the parent when appending a non-empty item.

Remaining tasks

User interface changes

API changes

Data model changes


Fix references to the deprecated Entity class

$
0
0

Fix references to the deprecated Entity class. It was renamed to EntityBase.

During the search for references I've found some more inconsistencies, which I hope could be fixed together.

[PP-1] Remove legacy Path Alias subsystem and make the "path_alias" module optional

Convert automated_cron, ban, dblog, syslog, system, update, and user module hook_help() to topic(s)

$
0
0

Additional People to Credit

There were several issues that had patches that were combined into this one. Additional people to credit, who worked on the other issues:
#3043460: Convert automated_cron module hook_help() to topic(s)
vadim.hirbu
BramDriesen
shwetaneelsharma

#3047585: Convert ban module hook_help() to topic(s)
lisagodare@gmail.com

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the automated_cron, ban, dblog, syslog, system, update, and user modules

Exception: Functionality in the System module that is related to themes should go in #3055055: Convert appearance-related modules: breakpoint, color, layout_builder, layout_discovery, field_layout module hook_help() to topic(s) instead.

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

  1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
  2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
      switch ($route_name) {
        case 'help.page.contact':
    

    And ends either at the end of the function, or where you find another case 'something': line.

  3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
  4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
  5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
  6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
  7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

  1. Apply the patch.
  2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
  3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
  4. Review the topic text that you can see on the page, making sure of the following aspects:
    • The text is written in clear, simple, straightforward language
    • No grammar/punctuation errors
    • Valid HTML -- you can use http://validator.w3.org/ to check
    • Links within the text work
    • Instructions for tasks work
    • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
  5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Remove BC layers from the entity system

$
0
0

Problem/Motivation

in #1730874: Add support for loading multiple revisions at once we deprecated doLoadRevisionFieldItems(), but left its use in doLoadMultipleRevisionsFieldItems(). In #3069043: Trigger an error on direct access of ContentEntityStorageBase::doLoadMultipleRevisionFieldItems() and mark it to be set abstract in Drupal 9 We deprecated calling ContentEntityStorageBase::doLoadMultipleRevisionsFieldItems directly and triggered an error, declaring the method would be abstract in Drupal 9

Proposed resolution

Remove the logic and make the method abstract

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Remove Firefox workaround for details focus effect

$
0
0

Problem/Motivation

We have a workaround for the details focus effect to make it more consistent with Chrome. However, this makes the details element focus inconsistent with some other elements on the same browser. Since this is presumably expected behavior in Firefox and not a bug, we should consider whether we want to have this workaround or not.

Proposed resolution

Remove the workaround and rely on Firefox's default behavior when it comes to details focus effects.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Untranslated menu items are displayed in menus

$
0
0

Problem/Motivation

We have a very nice translation system in place that is based on translating fields on entities. For many cases this work very well, but in some cases we need to special care. One of these places are menu items. Right now, when you display menu items, fx with the menu block from core, all menu items are displayed regardless of it being translated or not. This is bad for a few reasons.

  • Having a menu with mixed languages is often not desired for site builders / end users
  • Different menu blocks can have different requierments (e.g. filter main menu by current language, but not the footer menu)
  • It's not possible to hide menu items on certain languages (where they might not be relevant)

Steps to reproduce:

  1. Install Drupal with several langauge and enable menu translation
  2. Display the main menu with the core menu block
  3. Create some pages with links in the main menu
  4. Visit a page with the menu with a UI missing translations for menu items

Actual result:

All the menu items are displayed in the menu, untranslated in the original (or another) language.

Expected result:

Only the translated menu items are displayed in the menu.

Proposed resolutions

  • Display menu items either without a specific language or in the current language.
  • Make it possible to config each menu to display menu items either without a specific language or in the current language.
  • Make it possible to hide/display menu items on certain languages
  • Do nothing and let solutions live in contribs

Remaining tasks

  • Validate solutions with some sort of research project: user testing or a survey of multilingual site builders.
  • Decide what solution we should go for
  • Decide how to handle different types of menu items (from code. *.links.menu.yml, from views, from menu link entity)
  • Update issue summary
  • Test the proposed resolution

User interface changes

TBD.

API changes

None.

Data model changes

None.

Available work-arounds

Updating translations does not clear the JS asset cache so new translations are not loaded

$
0
0

Problem/Motivation

Found in #3086374: Make Drupal 8.8 compatible with PHP 7.4. LocaleJavascriptTranslationTest::testLocaleTranslationJsDependencies() is making the following assertion:
$this->assertTrue(strpos($content, $js_filename) < strpos($content, 'core/misc/drupal.js'), 'Translations are included before Drupal.t.');
But $js_filename does not actually appear in $content so this is always going to be true.

This shows that the cache used in \Drupal\Core\Asset\AssetResolver::getJsAssets() is not rebuilt after changing a translation.

Proposed resolution

Ensure the 'library_info' cache tag is cleared when a translation is changed and fix the test to ensure we don't get false positives in the future.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a


RSS view with fields give wrong URL from path field

$
0
0

Problem

RSS view with fields instead of content rendering in RSS view mode results in wrong URLs from path field (with pathauto enabled).

Instead of correct URL with http://mysite.domain/content/my-node-title we got http://mysite.domain/my-node-title.

Reproduced on multiple sites with current d.o D8 pathauto module.

  1. Edit 'Frontpage' view
  2. Select 'Feed' display
  3. Switch display mode from content to fields
  4. Add title, path, author, created field
  5. Configure fields in display mode settings. Link & GUID with permaLink = Path field
  6. Check URLs in preview output

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Drupal 9 readiness meeting / 11 November 2019

$
0
0

Meeting will happen in #d9readiness on drupal.slack.com.

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 9 upgrade of their sites are also welcome.
➤ Usually happens every other Monday at 18:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3093743`
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.
Gábor Hojtsy (he/him) Who is here today? Comment in the thread below to introduce yourself.
Alona OneillAlona from SF Taking notes for blog (edited) 
mikelutzHello all!
shaalOfer, OOTB maintainer
xjm
Gábor Hojtsy (he/him)hey Gábor core committer
lendudeLen from Amsterdam, trying to put the kids to bed after local version of halloween, so hands full but reading along!
berdirSascha, entity system maintainer, currently trying to improve the fallout of the path_alias issue
mradcliffeMatthew, taking a hot chocolate and crossword puzzle break.
dwwDerek from Oakland, CA. Trying to keep various contribs working with 8.7.x, 8.8.x, 8.9.x and 9.0.x. Fun!
larowlanLee from .au, just after 5am here
dan2k3k4 Dan from Amazee Labs, based in Zurich, just watching in
tedbowTed from Ithaca, NY, USA
mirom Miro from Slovakia, just keeping myself up-to-date
Gábor Hojtsy (he/him) Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.
shaalRector for Drupal in core
lendude#3091462: [policy, no patch] Agree to purge WebTestBase extending *TestBase classes outside the Simpletest module from D9 discuss if the comment from catch is enough to say go for it and remove all simpletest base classes
lendude#3093621: [META] Plan to get a stable D8/D9 release of the SimpleTest module for the removal of simpletest we probably want a stable contrib version, opened a meta to try to determine what we need to get it there
berdir#3093747: Add alias process service back (deprecated) and improve DX around BC path_alias services maybe, just created that and working on it now. more raising awareness than anything else, as it would need to land in next 8.8 release to be useful and avoid workarounds in e.g. subpathauto
dwwProbably not on topic at this point, but my recent experience makes me wish we had a 1 minor version delay between introducing the good new alternative of something and marking the old way deprecated... things marked for deprecation in 8.8.x that already have existing solutions in 8.7.x are easy. When we add the alternative and immediately deprecate in the same minor version, contrib maintainers have to add technical debt to our modules to still support old and new approaches conditionally...
dwwAlso wondering about when/how we can do disruptive markup changes to finally fix a bunch of bugs related to markup. If we can't break stuff in a new major release, when can we? ;)
Gábor Hojtsy (he/him) Progress towards Drupal 9 alpha1
mikelutz#2608062: [META] Requirements for tagging 9.0.0-alpha1
Gábor Hojtsy (he/him)we only have the jQuery fork issue here from the requirements ^^^
mradcliffe#3092563: Avoid overwriting .htaccess changes during scaffolding is probably not a blocker for alpha1, but would prevent testing for some people.
xjm@mradcliffe That issue confuses me because AFAIK it's exactly the current state -- you get the same behavior with a manual install or drush
xjmThe jQuery UI fork is going well; we've split out a number of followups that aren't alpha-blocking
xjm(For converting the tests to Nightwatch so we can run them and etc.)
mradcliffeYou're right, @xjm. I think the automatedness of composer makes it easier to overwrite changes, which might have been handled by patches in drush make in currently supported Drupal 7 and either a one-time scaffold using a composer project in Drupal 8. The steps for updating manually are to move files around and compare, which also is a different work flow then a manual update-in-place with composer.
mikelutzThe old drupal-composer/drupal-scaffold let you put excluded files in the ‘extra’ section. I always ended up listing robots.txt and .htaccess there when I customized them.
Gábor Hojtsy (he/him) Updating (misc) composer dependencies for Drupal 9
Gábor Hojtsy (he/him)#3091418: Update composer dependencies on 9.0.x
Gábor Hojtsy (he/him)I think @jibran has a solid plan there, although not sure we need to decide on all the outstanding dependency decisions ahead of doing the smaller ones that we are not gonna drop either way
mikelutzI’m afraid to try to update composer dependencies anymore.
xjmManuel started on this at AMS, but we could use some help splitting issues out etc.
xjmBit confused by the last comment as I thought the minimum PHP version was already set correctly?
mikelutzIt looks to be.
mikelutzMaybe he was looking at the 8.8 codebase when he commented.
xjmA lot of the test fails were also one issue, so I think we can chip away until we get just passing dependency updates. The decoupling is also done to the extent that it will be, as well. That ended with beta1.
mikelutzoh, nevermind, I see what he means.
xjmNo more decoupling for this major because we would have needed to deprecate things by now.
mikelutzUpdate the minimum version in core/composer.json to be PHP 7.2 compatible. means updated the minimum dependency version to the highest one that is 7.2 compatible
mikelutzfor each of the dependencies that we would want to update.
xjmShouldn't Composer already be resolving that (or declaring where it can't be resolved)?
mikelutzNot necessarily. We may have pinned something to ^1.x.x because we knew the 2.x version required php 7.1 or some such thing.
mikelutzWe just need to look at all the dependencies and see if any of the rest of them need a major version bump like twig or symfony.
xjmYah makes sense
mixologicI'm afraid to try to update composer dependencies anymorehttps://www.drupal.org/node/3089540 hopefully you've seen that and it makes less scaryness
mikelutzlol, yeah, I would try it with those instructions.
Gábor Hojtsy (he/him) Using rector to automate deprecated API use removal
Gábor Hojtsy (he/him)@shaal had a good experience setting this up, using some steps that were not necessarily evident
Gábor Hojtsy (he/him)do you want to write up a blog post about this @shaal?
shaal it's probably going to be more a length of a tweet
Gábor Hojtsy (he/him)@shaal hm, was there public docs you used that I missed?
Gábor Hojtsy (he/him)re your ambitious proposal of core inclusion I don’t think that is possible at all due to heavy 3rd party dependencies
Gábor Hojtsy (he/him)but it would be great to have a service where you press a button, it checks out the latest branch of the projects, runs this on it and gets you a patch?
Gábor Hojtsy (he/him)it would be really painful to add this to d.o but a 3rd party service is not unimaginable if someone is sufficiently inspired to do
shaalSo yeah, my experience was that it was very easy to set up.And at this stage it's just a POC.It seems like the main part that is missing, is adding each deprecation (do we have a list of most popular deprecation to the least?)So this tool, at any stage, even if partially working, the deprecations that are already included will help everyone to get to D9 faster/better.
dan2k3k4rector/rector or drupal8-rector/drupal8-rector ?
shaalI was testing https://github.com/drupal8-rector/drupal8-rector
shaal@Gábor Hojtsy (he/him) do you want to change the title of the thread to Drupal8-Rector ?
miromI tested version from Pronovix people some time ago, was there any progress? The very first version wasn’t very usable. For D9 it might be good policy that if you deprecate something, you should add a rule for rector, so it can be removed easily.
shaalyes!
shaalI wish that upcoming code deprecations for D10, will also include the rector code, which will make D9->D10 much easier and smoother.
Gábor Hojtsy (he/him)http://hojtsy.hu/blog/2019-may-24/analysis-top-uses-deprecated-code-drup... are the top deprecations
Gábor Hojtsy (he/him)I opened an issue at https://github.com/drupal8-rector/drupal8-rector/issues/21 to cover those
Gábor Hojtsy (he/him)(opened in May)
Gábor Hojtsy (he/him)we need people to work on this, that is what it comes down to, @mxr576 gifted this to the community but is not working on it
miromcan we use rector as is to upgrade between symfony versions given there already are rules for that?
Gábor Hojtsy (he/him)do you want to try?
miromsure, my christmas are empty for now
shaalRector already have this for Symfony -Let's say you pick the symfony40 set and you want to upgrade your /src directory:# show a list of known changes in Symfony 4.0vendor/bin/rector process src --set symfony40 --dry-run# apply upgrades to your codevendor/bin/rector process src --set symfony40
shaal(from https://github.com/rectorphp/rector#a-prepared-sets)
shaalAnd it can upgrade your code from PHP 5.3 to PHP 7.4
shaalThe report from May says it found 7843 calls to the deprectated function drupal_set_messageThis function is already part of the existing POC, so in theory no one has to manually fix drupal_set_messagehttps://github.com/drupal8-rector/drupal8-rector/blob/master/src/Rector/... (edited) 
dan2k3k4tested out drupal8-rector but I see it gives weird results like the following diff:
mxr576It automatically adds all use statements that could be necessary when it replaces deprecated code, because it cannot know whether those are already inherited from the parent or not. So you have to remove those with code style checkers later, or with PHPStorm's "Optimize imports" feature.Btw, there is an open PR that is probably related to this, that I haven't had time to finish yet: https://github.com/drupal8-rector/drupal8-rector/pull/15/files
mxr576 we need people to work on this, that is what it comes down to, @mxr576 gifted this to the community but is not working on itYeah, I would like to continue the work on it, but I do not have a capacity for this in my free time nowadays. In working hours, I am mostly traveling and participating in workshops this month. I am trying to follow Rector related threads here. I am very happy that the community started to see the real potential in Rector and also ready to contribute to the project
Gábor Hojtsy (he/him) Simpletest removal, discussion of base classes and contrib module (edited) 
Gábor Hojtsy (he/him)@lendude suggested #3091462: [policy, no patch] Agree to purge WebTestBase extending *TestBase classes outside the Simpletest module from D9 and
Gábor Hojtsy (he/him)#3093621: [META] Plan to get a stable D8/D9 release of the SimpleTest module
lendudeSo the main question about the base classes was, if we remove them from core, we might still end up breaking contrib tests, which we are trying to prevent with the whole move-to-contrib thing
lendudeIf the answer is ‘yes we are fine with this small break’ then we can just close it and start to remove all those base classes
dwwTrue, but as catch writes in the issue, the un-breaking solution is a very small change to the use statement. And if there's an official release of simpletest contrib now/soonish that provides them, folks can already start using that and porting their tests to it.
dww(if they don't want to already do the right thing and port to the newer base classes)
dwwFWIW, as someone holding down the "please don't break us" position a lot these days, I'm +1 on a break of this kind. ;)
lendudeAh ok, so the confusion might be over which base classes I’m refering to, I mean like ViewsTestBase and BlockTestBase and the like, these will not be moved to contrib.
lendudeOr that was never part of the plan as far as I know
lendudeThey will just get deleted
lendudeSo if you are using them you will have to make your own version of them
lendudeThe same goes for all the test traits that are not in the simpletest module in core but spread through all the other modules
dwwOHH, yeah, I totally misunderstood. Why are we removing ViewsTestBase? Is there an issue about that?
xjmThose have mostly been deprecated for a very long time
xjmViewsTestBase extends WebTestBase and etc.
dwwOh, sorry, I'm confused. ViewTestBase (not deprecated) vs. ViewsTestBase (deprecated).
lendudeYeah, so we have two versions of all those base classes, a WebTestBase version and a BrowserTestBase version, same goes for all the test traits, and the WTB versions have been deprecated
lendudeI think they are both calles ViewsTestBase, just with a different namespace
dwwDoesn't look like it... see core/modules/views/tests/src/Functional/ViewTestBase.php
dwwNo s in there. But yeah, kinda confusing.
lendudeYeah but for block/comment/node they will probably be the same (views always has to be different )
dwwSo, we don't appear to have gotten any clarity in here. Do we need a plan? Do we just stop holding the hands of people still using WTB?
lendudeWell at the very least I’ll update the IS a bit to make it clearer what specific cases this is about
Gábor Hojtsy (he/him) Disruptive markup changes, when are they possible?
Gábor Hojtsy (he/him)@dww raised this
Gábor Hojtsy (he/him)if @lauriii would be online, I would summon him
dwwE.g. #3078334: Datetime and Datelist element titles use inaccessible <h4> for field labels
dww(Dang Slack... that's "Datetime and Datelist element titles use inaccessible

for field labels")

Gábor Hojtsy (he/him)#2659890: [Plan] Drupal 9 markup and CSS backwards compatibility is the high level plan
dwwandrewmacpherson wants us to use a fieldset for datetime, not our weird hacks. That'd be a Big Change(tm). It's mostly working, but I don't really want to sink too much time into it if the answer is "we can make changes of that scale in D10"
dwwRe: 2659890 -- Indeed. See my comment #37. I specifically asked about this and there's been no answer. I know we're all juggling Too Many Things(tm), so no judgement/shame. I'm just looking for answers so I can plan my time/efforts accordingly. Thanks!
xjmD9's Stable will be the latest markup output by modules
xjmThe internal themes and the module markup can change in minors; stable will change with each major
xjmHowever, we're also retaining D8's Stable in core for BC
xjmSo it's like the PHP deprecation process in that way -- the public API only changes in the major version and only based on changes already made with BC
dwwRighto. So between now and stable_9 being "tagged" / "forked" etc, we change module markup, can fix internal themes, but leave classy and stable broken. And folks extending / using stable or classy remain broken until they port their stuff. Is that a fair summary?
xjm"broken"?
xjmI don't understand what you mean
dwwInaccessible. #states doesn't work, etc. ;) Depends on the issue in question.
xjmWe've made changes to Stable and Classy before for accessibility fixes
dwwTo fix these bugs, we have to change markup.
dwwBut we can't change markup or we break BC.
xjmIt's one of the categories of disruptive bug fixes we do change in the stable base themes
dwwOkay, but other bugs don't have accessibility implications.
xjmDepending on the impact vs. the disruption
dwwE.g. #states, #description_display not being honored, etc.
xjmI can't speak to those specific issues... up to the frontend framework manager
xjmBut those sound like render API and not templates
dwwWell, it's a case of the core templates not handling stuff render API says should be available.
xjmAnyway, yes, the correct approach is still to fix what can be fixed with BC in minor releases. The major release version is being started basically now, same as with backend deprecations ending with the 8.8 beta
dwwWhat about a situation where a render API change means an entire template and preprocess() pipeline is dead code? E.g. we stop having a separate datetime-wrapper* and we just re-use fieldset ?
xjmReally should be discussed on the specific issue, but the continuous upgrade path always means we should be making the change with BC in minor releases first
Gábor Hojtsy (he/him) Change policies for Drupal 9 about deprecation vs. new API addition timing?
Gábor Hojtsy (he/him)@dww proposedmy recent experience makes me wish we had a 1 minor version delay between introducing the good new alternative of something and marking the old way deprecated... things marked for deprecation in 8.8.x that already have existing solutions in 8.7.x are easy. When we add the alternative and immediately deprecate in the same minor version, contrib maintainers have to add technical debt to our modules to still support old and new approaches conditionally...(edited)
Gábor Hojtsy (he/him)we can still improve the 8.8 deprecation messages to add notes where the code was available before
Gábor Hojtsy (he/him)the 8.7 ones go into full-on possibility in a month, so not sure that makes any difference anymore, but the 8.8 ones would be good to revisit in terms of the deprecation text to be more clear when the replacement API was already there before
larowlanthe alternative is when we don’t deprecate - we end up with a long tail of technical debt because new usages sneak into core. If you contrast say the entity.manager split (an early deprecation which didn’t fail tests) with the later ones, it took us muuuuucccch longer to clean up the debt
larowlanbut it would be ideal if we could get smarter about the errors
larowlanalmost like a wrapper around trigger_error that used some version parsing smarts
mikelutzRealistically, attempting to postpone the deprecation 1 minor version isn’t practical for a number of reasons. It’s technical debt that just won’t get fixed, and not adding the deprecations immediately means that we wouldn’t catch new core patches that might use old code we are about to deprecate.
berdirYes, not deprecating results in 2 API's and it's hard to use the right one. See current assert methods that we undeprecated where method autocomplete in phpstorm is not very helpful
Gábor Hojtsy (he/him)another alternative for Drupal 9 to 10 is stop deprecating two minor releases out
mikelutzbut @larowlan is right, the answer is in tooling and the new deprecation message format.
mikelutzBecause we need to not say deprecation suppression is on or off in the drupalci.yml. We need to declare the deprecation level that the contrib project expects to be compatible with.
Gábor Hojtsy (he/him)I’m trying to find examples of deprecation messages where we added a note of prior replacement, cannot find them, but I know I’ve seen them.
mikelutzWe need to say deprecation-level: 8.7 and then suppress all deprecations added in 8.8+ during that test run. (edited) 
Gábor Hojtsy (he/him)@mikelutz that would still require branching for the two versions to support core support timelines
Gábor Hojtsy (he/him)(and be able to do security fixes)
berdirAnd for things that we are deprecating properly, I really don't see the problem. we had a long discussion on this already and I can't say anything that I've said before: getting deprecation messages in contrib is a good thing. It means that your module still works, and you can actually rely on core ensuring this with legacy test coverage. And yes, better tools there will help, by if you can say I require 8.6 and then you don't want to see deprecations for 8.6 and older.
mikelutz@Gábor Hojtsy (he/him) no more so than waiting a minor to add the deprecation. In my case, contrib would declare their deprecation level even with the security minor or the stable minor, whichever they prefer.
mikelutzWe would still ADD the deprecation at the time we add the new api, but contrib wouldn’t SEE it until they chose, be that 1 minor later, or 2 minors later, or right away.
mixologicThis is something I've had opinions on for a long time. Deprecation messages should be treated like phpcs or other 'standards' violations and not treated as a build failure, unless the maintainer wants that.
berdirwhere we need to be extra careful is things that break contrib, even if it's just tests and make that as easy as possible to deal with, or things were we can easily be forward compatible. E.g. backporting just the interface for TrustedCallback to 8.7 would allow contrib to use that that alreeady right now without ugly hacks that have to be cleaned up again.
mixologicThe issue people keep running into is "how to I have 'passing' tests" - which wouldnt necessarily be the target if people could have varying degrees of control over what a deprecation means in the context of phpunit.
mikelutzAt the end of the day, this is all optics. No matter what you do you still have the same 3 options. 1) wait to fix deprecations until your supported core has the replacement, 2) use funky hacks to get a version that works with all core versions 3) make a new branch for a new core minor and up the minimum supported core version and fix your deprecations there.
mixologicBut the phpunit symfony bridge seems to either give us useless counts if we dont want to fail the build. What we need is the full error messages, but not fail tests.
mikelutz@mixologic precisely. Your module is not broken or incompatible with a newer core versions because tests fail due to deprecations.
Gábor Hojtsy (he/him)@mikelutz @mixologic filtering deprecation messages does not solve the problem of not being able to be N and N+1 major version compatible with the same codebase due to the overlapping security coverage of N.last-1 and N+1 while N.last-1 has deprecated APIs (edited) 
mikelutzBut it does look bad, and I see why maintainers want to keep green test runs.
mixologicright. They shouldnt fail. Unless you want them to. Testing against the security/supported versions, yeah, fail on deprecations. Testing against the prerelease or dev version.. well, no deprecations shouldnt be a failure.
mixologic@Gábor Hojtsy (he/him) you mean in the instance where N.last-1 only has the deprecated api, N.last has both the deprecated API and the new API, and N+1 only has the New api?
dwwYeah, my specific proposal is probably won't fix. It's tech debt for core. I'm just a bit sad that core avoiding technical debt means contrib has to add our own, or we have to stop supporting things we should keep supporting.
mikelutz@Gábor Hojtsy (he/him) I don’t understand why it doesn’t. Yes, it you want to support security, stable, and development then you are limited to the api level of the security version, but your same codebase is still compatible with stable and development minors too. Your tests aren’t failing, they are just giving deprecation messages that you can’t fix yet because you have chosen to remain on the security version api.
mixologicI think thats also a somewhat confusing stance that core took with regards to the 'security support' of core, and adding in that additional 6 months. It was always somewhat ill defined whether or not contrib maintainers should support that version of core etc
dwwIt's also too bad d.o prevents a 9.x-* branch if that's the "recommended" solution to avoid technical debt. If I need a new branch to work with 9.x, let me tag it as such. Yeah, I know we hope that contrib will be Pure Semver(tm) sometime Soon, but that's not working yet. So meanwhile, it's confusing and weird that I'm supposed to make "8.x-2.0" as my D9-compatibile release. (retracted) (edited) 
mixologicWell, its not that we're preventing a 9.x-* branch its that they're no longer called 9.x-*
mikelutzIf we allowed it, it would break the plan to add semver.
mixologicbut yeah, we cannot have a situation where there exists the same version on both 8.x and 9.x
mikelutzI know it’s a bit weird, but when we drop the 8.x/9.x it would be bad if you have 8.x-2.0 and 9.x-1.0.
dwwFair enough.
mixologicIf we were to get a little bit more finesse we could allow 9.x- for the time being, and just not allow releases to be made for versions that already exist as 8.x- versions.
mixologicBut that would also be confusing and weird.
dwwRight, the time is better spent marching towards the future, not helping the past limp along behind us.
mikelutzRight, if you did 9.x-3.0 you would be fine, there’s just no easy way to communicate or force that.
mixologicSo, this is sortof a dumb idea, but what if we had a different deprecation strategy.
mixologicRight now the strategy is, say method_A() is old
mixologicgets marked deprecated and becomes method_B().
mixologicThen, when drupal 9 comes out, 'deprecated code is removed'
mixologicwhat if
mixologicnevermind. IM going to suggest what we're already doing.
mikelutzlol.
mikelutzI thought you were going to say we should just leave poor method_A() alone. I mean, what’s wrong with him anyway, and why is method_B() any better..
mixologicI was going to say leave it there in 9.0, and just have it point to B, until 9.1 and then remove it
mixologicIt's almost as if we should just not do deprecation removal at the major version boundary only, and instead deprecate in version N, targeted for removal in N+3
mixologicor N+4 or something
mikelutzthat’s bad semver.
mixologicthat is true
Gábor Hojtsy (he/him)@mikelutz the problem with deprecations in N.last-1 is that it stops being core-supported when N+1 comes out
mixologicYeah, I think the real answer here is that 8.7 should have been the final place for deprecations for 9.x, and 8.8 and beyond should have been all 10x deps
Gábor Hojtsy (he/him)IMG_20191111_205643.jpg 
mikelutzOkay, you are talking about major version boundaries. (edited) 
mixologicbut I think that is only the benfit of hindsight
Gábor Hojtsy (he/him)so if your contrib wants to support N and N+1 majors then it can not do that before N+1 comes out, it can only do that with some delay
Gábor Hojtsy (he/him)yeah that is what I wrote in https://drupal.slack.com/archives/CDDD98AMN/p1573501439231900?thread_ts=...
mikelutzYes, fine. And that’s true.
Gábor Hojtsy (he/him)unless, we stop deprecating in N.last-2
mixologicRight, and not 'stop deprecating' but 'stop deprecating for removal in N+1', they become 'deprecated for removal in next major +2'
mikelutzI think that’s too much.
mikelutzBut I also think that contrib branching isn’t a bad thing. They shouldn’t have to support that security branch other than security fixes.
mikelutzIf someone is on the security core version, they probably don’t want active development on their contrib either.
mixologicSo, we need tooling that can warn/distinguish between "removed in the next major version" or "removed in the next major version +1"
mixologicwe already need that now, as we're kinda hamstrung in deprecating things in the 8.9/9.0 cycle
Gábor Hojtsy (he/him)@mikelutz branching is a difficult psychological thing, previously because people were forced to do a new branch for Drupal 6, 7, 8, etc. they took the opportunity to refactor their stuff even if the API diff was not that significant (eg. between 6 and 7) — if we can decouple branching from supporting a new major version, then the “let’s refactor this shit now that I have a new branch” would not happen at the same time in contrib as the new core major is coming out
Gábor Hojtsy (he/him)its not just a tooling question, it is a human question as well
mikelutzSure, but it’s a psychological thing, and its why we need contrib semver. once it’s a minor branch and not a major branch the psycological burden will be lowered.
dwwNote: even though Git is Great, I also consider a new branch "technical debt" I have to maintain. It would still require more effort on my part to maintain my module, I have to remember to cherry-pick stuff at the right time, create separate releases + release nodes, etc, etc.
mikelutzbut you don’t. It’s not a supported branch, it’s just the last version to work with the old core.
dwwNot if it's my 8.7.x-compatible branch.
dwwAnd I have bugs (inconceivable, I know!), and I need to fix them.
mikelutzbut not in your 8.6 branch.
mikelutzAnd not in your 8.7 branch after December 4.
dwwHuh? my 8.7.x branch needs to live until 8.9.0 is out.
Gábor Hojtsy (he/him)@mikelutz why? if there is a security release, Drupal 8 is still supported until November 2021… even if a maintainer stops fixing regular bugs
mikelutzIf core is not fixing bugs in 8.7 after December 4th, why do you feel you need to fix bugs in your contrib branch for 8.7?
Gábor Hojtsy (he/him)@mikelutz core will fix at least security bugs in 8.7 until next summer (edited) 
mikelutzYes, and the possibility of needing to do a security backport would be the purpose of contrib creating a new branch. But what are the odds of any particular module needing to do that, and how huge is the actual added workload in the event that that happens?
mikelutzIf you chose not to backport bugfixes to that branch.
berdirand if we consider long-term, then I assume that following the removal of the 8.x prefix, we'll also allow contrib to do patch releases? (because right now each release is exposed to composer as a minor release). So instead of having to start a new major version, you can just do a new minor version, and a security/bugfix release could still be a patch release
dwwYes, the plan is to allow major.minor.patch(extra)
dww(just like we already do with core)
dwwwhether contrib maintainers will use the right values for these based on what they're doing is anyone's guess. ;)
dww(in fairness, just like now)
berdirand until then, I believe I've already seen a workaround that goes like this: you have 8.x-1.0, then you release 8.x-1.1 that requires 8.7, now you have to do a security release and want to still support 8.6, then you could do 8.x-1.2 based on 8.x-1.0, document that this is based on 8.x-1.0 and only has the security fix, and at the same time release 8.x-1.3 that is based on 8.x-1.1 and has the security fix too but isn't flagged as a security release (so that people could update to 1.2 and don't get a security-updates message). not perfect, but I could live with that until we have full semver (edited) 
Gábor Hojtsy (he/him)@berdir that sounds like a recipe for someone to bork a site who tries to update and gets downgraded
berdirif they update from 1.1 to 1.2, yeah, but you could document that in the SA. anyone who just does updates the module with composer/drush update would get 1.3, you need to specifically download 1.2 for it to break. as I said, it's not great, but I'd prefer that over doing a new major version until we have patch releases
berdiralso, you could likely even mark 1.2 as incompatible with D8.7, which means it would be impossible to update from 1.1 to 1.2 as 1.1 would require 8.7. So I think this would work quite well. just like composer will be smart enough to only update to 1.2 then as long as you're still on 8.6
Gábor Hojtsy (he/him)ok I posted the blog post I had drawn up the figures for in my head last week in our discussion with @dww https://twitter.com/gaborhojtsy/status/1194010636763705344
Alex Morenothanks for that post/graph @Gábor Hojtsy (he/him), I know it's going to be pretty useful for some conversations ^^
Alex Morenoand everyone else
Gábor Hojtsy (he/him) All-contrib deprecation browser launched! (edited) 
Gábor Hojtsy (he/him)I build an all-contrib deprecation browser based on the data from drupal.org’s all-contrib jenkins runs (that are soon going to display the data on d.o project pages too, @mixologic is working on that)
Gábor Hojtsy (he/him)there are still some small things broken here and there and there are already new features lined up, but see https://dev.acquia.com/drupal9/deprecation_status for now
Gábor Hojtsy (he/him)allows you to browse projects vs. deprecated api use
Gábor Hojtsy (he/him)or browse from the errors point of view, eg. which top projects continue to use drupal_set_message() and how much, etc.
mradcliffeWow, that's really nice. Thank you.
larowlannice work, this will be awesome for DS sprint later in the month (edited) 
berdir @Gábor Hojtsy (he/him) btw, even though WebTestBase deprecation says deprecated in 8.8, the replacement has been around forever, so it could easily be a "Fix now". not sure if you can influence that manually
Gábor Hojtsy (he/him)@berdir I’ve been looking for this in #7 as well, we have some deprecation messages that have “the replacement is available from so and so prior version”, but I cannot find any of those now
Gábor Hojtsy (he/him)@berdir I don’t know the exact wording, because now that we have this search tool, the errors tab could easily find them
Gábor Hojtsy (he/him)https://dev.acquia.com/drupal9/deprecation_status/errors
berdirok, haven't seen an example of that, would indeed be useful
Gábor Hojtsy (he/him)I’ve seen it go by… that would immediately help this tool and people purely using drupal-check, etc.
Gábor Hojtsy (he/him)I can manually tweak the results of this too like we do in Upgrade Status, but the best would be to fix the source data
Gábor Hojtsy (he/him)that would fix all the tools, including people using phpstorm, etc.
Gábor Hojtsy (he/him) Thanks all for coming, see you in two weeks: #3093746: Drupal 9 readiness meeting / 25 November 2019

system_requirements() strips core compatibility in really fragile and dangerous way when comparing versions

$
0
0

Problem/Motivation

system_requirements() includes this:

        $version = str_replace(\Drupal::CORE_COMPATIBILITY . '-', '', $required_file->info['version']);
...
            'description' => t('@name requires this module and version. Currently using @required_name version @version', ['@name' => $name, '@required_name' => $required_name, '@version' => $version]),
\Drupal::CORE_COMPATIBILITY is "8.x".

So we str_replace() "8.x-" with an empty string.

However, we're not careful about doing so only at the beginning of the version string.

So, if you somehow are dealing with a version string that contains '8.x-' somewhere you don't expect, all hell breaks loose.

Reasons you might have a version string that will be wrongfully clobbered include:

  1. A contrib module is upto 8.x-8.x branch and you're using the -dev release.
  2. You applied #3093130: Between alpha1 and X.Y.0 official \Drupal::VERSION should not be "8.8.0-dev" since it doesn't work for Semver::satisfies() and core's version is 8.8.x-dev
  3. You're using git_deploy and a Git checkout of core, in which case core thinks its version is 8.8.x-dev (I think).
  4. ...

Proposed resolution

If we have to strip this off, make sure we only do it at the beginning of the version string.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

@see links in ckeditor module point to deprecated version of docs

$
0
0

Problem/Motivation

There are a couple of code comments in core/modules/ckeditor that include this:

@see http://docs.cksource.com/CKEditor_3.x/Developers_Guide/Styles

If you follow the link, you land on a big red warning:

This website contains links to software which is either no longer maintained or will be supported only until the end of 2019 (CKFinder 2). For the latest documentation about current CKSource projects, including software like CKEditor 4/CKEditor 5, CKFinder 3, Cloud Services, Letters, Accessibility Checker, please visit the new documentation website.

There's also this link:
* see http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.resourceManager.h....

Proposed resolution

Update the links to point to the new locations for those docs:

Remaining tasks

  1. Do it
  2. Review
  3. RTBC
  4. Commit

User interface changes

-

API changes

-

Data model changes

-

Release notes snippet

-

Create a core.api.php section about the Context system

Viewing all 295277 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>