Problem/Motivation

Drupal can use a number of different UUID generation schemes depending on which environment it's operating within.

It should display the current generation method in the status page.

Optionally, we should consider whether Uuid::isValid() should be marked as final, so that our determination of validity is the one and only allowable one.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Original Issue Summary

This is a followup issue to #1252486: Low level UUID API in core for code changes after the patch in #81 was committed.

Per sun's comments in #87, the last two in the list were implemented in Pol's patch in #88:

  • Should Uuid::isValid() use the final keyword? (not included in the patch here)
  • Make $plugin a static class property (creates a new $instance property on the Uuid class as a result)
  • Move the default plugin in Uuid::determinePlugin() into an else block

Other changes introduced via Pol's patch in #88:

  • Add a requirement to display the current UUID plugin implementation in the status report in system.install

This patch also adds a use Drupal\Component\Uuid\Uuid; to system.install, otherwise installation will fail.

The follow-up patch in #88 removed Uuid::isValid() and added UuidInterface::validate() and UuidPhp::validate() - as per my understanding of the docblock in Uuid::isValid(), plugins should not implement validation, and it looks like this would break tests, so I did not roll those changes in.

CommentFileSizeAuthor
#1 1738620-1.patch2.64 KBstar-szr
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

star-szr’s picture

Status: Active » Needs review
FileSize
2.64 KB

Patch.

Status: Needs review » Needs work
Issue tags: -UUID

The last submitted patch, 1738620-1.patch, failed testing.

star-szr’s picture

Status: Needs work » Needs review
Issue tags: +UUID
sun’s picture

Status: Needs review » Needs work
+++ b/core/modules/system/system.install
@@ -55,6 +56,12 @@ function system_requirements($phase) {
+  $requirements['uuid'] = array(
+    'title' => $t('UUID plugin implementation'),
+    'value' => $uuid->determinePlugin()
+  );

This will output the fully qualified class name on the requirements page. I guess we want to "prettify" that a bit (e.g., "PECL extension", "COM extension", "Drupal")

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Mile23’s picture

Title: Followup to Low Level UUID API in core » Display UUID generator in status, mark Uuid::isValid() final
Version: 8.1.x-dev » 8.2.x-dev
Issue summary: View changes

Updating this issue. :-)

Uuid no longer functions as a plugin. It's a service which is initialized in either CoreServiceProvider::generateUuid() (8.1.x) or CoreServiceProvider::alter() (8.2.x)

Therefore none of the concerns about plugins apply any more.

All that remains is the functionality of displaying the UUID generator in the status page, and also figuring out whether Uuid::isValid() should be marked final.

I'd say it's safe for this issue to concentrate on displaying the generator in the status page, if we're doing that.

Bumping up to 8.2.x since this is a code change.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.