- Issue created by @pgndrupal
I think this may duplicate 🐛 Update manager compatibility logic is missing if you're on a -dev release of core Active or 🐛 Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\update\ProjectCoreCompatibility->getPossibleCoreUpdateVersions Active . It looks like you commented on one of them. Is this issue distinct?
re: 3135663, i'm not on a dev release of core (that was the only option I had in the dropdown). rather i'm on 11.1.0 *release*.
i _do_ keep bumping into these TypeError issues -- so far, somewhat randomly & intermittently (e.g., https://www.drupal.org/project/drupal/issues/3467538#comment-15901089 🐛 Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\update\ProjectCoreCompatibility->getPossibleCoreUpdateVersions Active ).
atm, in my current state, _this_ is fully repeatable/reproducible, here.
dunno what specific info's helpful; can grab if asked.
This, I think is the same error as 🐛 fatal error on `update` module enable on composer-managed D11.1.0 instance Active . 🐛 fatal error on `update` module enable on composer-managed D11.1.0 instance Active doesn't have a stack trace so I don't know if this is quite the same. My investment in this right now is just determining if we have a duplicate issue.
@cliefen
> 3495587 ... doesn't have a stack trace
the OP here is with
```
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
$config['system.logging']['error_level'] = 'verbose';
```
what specifically are you looking for beyond that? an `strace`? other?I am seeking to understand if this issue duplicates the previously-reported 🐛 Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\update\ProjectCoreCompatibility->getPossibleCoreUpdateVersions Active . That is all. I wrongly referred back to this very issue in comment 4. Sorry for that confusing comment.
This issue has a stack trace. The other does not. Both issues describe the bug reproduction environment, which I am beginning to think does not influence the bug occurring. Neither has steps to reproduce. There must be some steps to reproduce, even insomuch as an element of the environment may be the reproduction.
The stack trace indicates that
$this->existingCoreVersionis an object when it should be a string. How this is happening is a bit of a mystery.> This issue has a stack trace. The other does not.
+1
> Neither has steps to reproduce.
the `drush pm:install update` step is all that's needed to reproduce the behavior, _here_. leaving it UNINSTALLED (i.e., disabled) cures it here ...
i understand you're looking for something that can be reproduced _elsewhere_; i don't have that atm.
i notice that `TranslatableMarkup` seems to be common, at least in some. no idea yet if that's a red-herring or not.
Are there contributed or custom modules present in the Drupal installation that produces this bug?
yes, there are.
no, i've not been able to bisect.
fwiw, in this specific instance here:Core Announcements (announcements_feed) Enabled 11.1.0 Core BigPipe (big_pipe) Enabled 11.1.0 Core Block (block) Enabled 11.1.0 Core Block Content (block_content) Enabled 11.1.0 Core Breakpoint (breakpoint) Enabled 11.1.0 Core CKEditor 5 (ckeditor5) Enabled 11.1.0 Core Comment (comment) Enabled 11.1.0 Core Configuration Manager (config) Enabled 11.1.0 Core Contact (contact) Enabled 11.1.0 Core Contextual Links (contextual) Enabled 11.1.0 Field types Datetime (datetime) Enabled 11.1.0 Core Database Logging (dblog) Enabled 11.1.0 Core Internal Dynamic Page Cache (dynamic_page_cache) Enabled 11.1.0 Core Text Editor (editor) Enabled 11.1.0 Core Field (field) Enabled 11.1.0 Core Field UI (field_ui) Enabled 11.1.0 Field types File (file) Enabled 11.1.0 Core Filter (filter) Enabled 11.1.0 Core Help (help) Enabled 11.1.0 Core History (history) Enabled 11.1.0 Field types Image (image) Enabled 11.1.0 Field types Link (link) Enabled 11.1.0 Core Custom Menu Links (menu_link_content) Enabled 11.1.0 Core Menu UI (menu_ui) Enabled 11.1.0 Core MySQL (mysql) Enabled 11.1.0 Core Node (node) Enabled 11.1.0 Field types Options (options) Enabled 11.1.0 Core Internal Page Cache (page_cache) Enabled 11.1.0 Core Path (path) Enabled 11.1.0 Core Path alias (path_alias) Enabled 11.1.0 Core Search (search) Enabled 11.1.0 Core Shortcut (shortcut) Enabled 11.1.0 Core System (system) Enabled 11.1.0 Core Taxonomy (taxonomy) Enabled 11.1.0 Field types Text (text) Enabled 11.1.0 Core Toolbar (toolbar) Enabled 11.1.0 Core Update Manager (update) Disabled 11.1.0 Core User (user) Enabled 11.1.0 Core Views (views) Enabled 11.1.0 Core Views UI (views_ui) Enabled 11.1.0 Administration Admin Toolbar (admin_toolbar) Enabled 3.5.1 Administration Admin Toolbar Search (admin_toolbar_search) Enabled 3.5.1 Administration Admin Toolbar Extra Tools (admin_toolbar_tools) Enabled 3.5.1 Other Composer Deploy (composer_deploy) Enabled 8.x-1.10 Development Devel (devel) Enabled 5.3.1 Encryption Encrypt (encrypt) Enabled 8.x-3.2 Spam control Honeypot (honeypot) Enabled 2.2.0 Security Key (key) Enabled 8.x-1.19 Mail Mail System (mailsystem) Enabled 8.x-4.5 Other Pathauto (pathauto) Enabled 8.x-1.13 Other Redirect (redirect) Enabled 8.x-1.10 Performance Redis (redis) Enabled 8.x-1.8+3-dev Security Security Review (security_review) Enabled 3.1.1 Mail SMTP Authentication Support (smtp) Enabled 8.x-1.4 Security Sodium (sodium) Enabled 3.0.0 Security Two-factor Authentication (TFA) (tfa) Enabled 8.x-1.9 Other Token (token) Enabled 8.x-1.15 Webform Webform Devel (webform_devel) Enabled 6.3.0-alpha3+7-dev Webform Webform UI (webform_ui) Enabled 6.3.0-alpha3+7-dev Webform Webform (webform) Enabled 6.3.0-alpha3+7-dev Core Claro (claro) Enabled 11.1.0 Core Olivero (olivero) Enabled 11.1.0with _that_ simply enabling `udpate` causes the error.
the only logs i've seen, i've shared.At a glance it may be composer_deploy, because it modifies update information. I would try uninstalling it first.
it was already happening prior to `composer_deploy` installation; i'd installed that while attempting to deal with this.
that said, specifically,
drush pm:uninstall composer_deploy drush pm:install composer_deployand, immediately, at nav to `https://dev.pgnetwork.net/admin/config`
The website encountered an unexpected error. Try again later. TypeError: Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\update\ProjectCoreCompatibility->getPossibleCoreUpdateVersions() (line 83 of core/modules/update/src/ProjectCoreCompatibility.php). ...Is it still the case when the module code is not present? Update manager looks at all present extensions.
For what it's worth that site doesn't have any particularly rare modules. I am trying to remember whether (and where) update data is cached...
as above
drush pm:install update drush pm:uninstall composer_deploy*AND*
composer remove composer_deploy drush cr composer show | grep -iE "deploy|update" (empty) drush pm:list | grep -iE "deploy|update" Core Update Manager (update) Enabled 11.1.0now, NO WSOD error at /admin/*; poking around the site, can't atm get it to replicate.
if not a fluke, `drush pm:install` does not seem sufficient?
also, now, checking status report @ https://example.com/admin/reports/status#warning ,
1 warning
Drupal core update status No update data available No update information available. Run cron or check manually. Cron maintenance tasks Last run 3 seconds ago (more information)re-exec'ing cron doesn't cure.
i can't find it in my scribbled notes atm, but iirc, composer_deploy was supposed to solve for the missing update info in a composer-installed Drupal instance
The TypeError exception is being thrown at this line:
if (!isset($core_releases[$this->existingCoreVersion])) {$this->existingCoreVersionis set in the class constructor like so:$this->existingCoreVersion = $core_data['existing_version'];.AFAICT, the only time in core that the
'existing_version'property can be set to TranslatableMarkup is in core/modules/update/update.compare.inc:if (isset($info['version'])) { <snip ...> } else { // No version info available at all. $install_type = 'unknown'; $info['version'] = t('Unknown'); $info['major'] = -1; } // Finally, save the results we care about into the $projects array. $projects[$key]['existing_version'] = $info['version'];I'm not sure how to get in a state where version info for Drupal core itself would be missing, but it's possible that the composer_deploy module touches some of that metadata, so there might be something in there that causes the version to get unset.
Nevertheless, the code in ProjectCoreCompatibility can be hardened to detect whether the existing version is not a string, using logic similar to what Package Manager does:
if ($existing_version instanceof TranslatableMarkup && $existing_version->getUntranslatedString() === 'Unknown') {So in ProjectCoreCompatibility, it could look something like:
public function __construct(array $core_data, array $core_releases, array $supported_branches) { if (isset($core_data['existing_version'])) { $this->existingCoreVersion = $core_data['existing_version'] instanceof TranslatableMarkup ? $core_data['existing_version']->getUntranslatedString() ? $core_data['existing_version']; $this->possibleCoreUpdateVersions = $this->getPossibleCoreUpdateVersions($core_releases, $supported_branches); } }Alternatively, probably should consider enforcing
versionto be a string (making it translatable doesn't make much sense IMHO), so
changing$info['version'] = t('Unknown');to$info['version'] = 'Unknown';might be a good place to start. That code dates back a long way (at least to 2007?), though, so not sure if there'd be any side effects from doing that.- Merge request !10669Draft: Issue #3495587: Make sure existingCoreVersion is not TranslatableMarkup. → (Open) created by godotislate
For a workaround until someone identifies the bug in Composer Deploy or there's consensus on a fix otherwise, I put up MR 10669 with the ProjectCoreCompatibility constructor change mentioned in #15. The diff can be downloaded and applied locally as a patch.
fwiw, confirming
drush core-status | grep -i version Drupal version : 11.1.0 <--- release, not dev branch PHP version : 8.4.2 Drush version : 13.3.3.0 pushd web curl -s https://git.drupalcode.org/project/drupal/-/merge_requests/10669.diff | patch -p1 patching file core/modules/update/src/ProjectCoreCompatibility.php popd composer require drupal/composer_deploy drush pm:install composer_deploy drush pm:list | grep -iE "deploy|update" Core Update Manager (update) Enabled 11.1.0 Other Composer Deploy (composer_deploy) Enabled 8.x-1.10no more FATAL error, so far. the two mods can coexist.
@ status report, i DO see now/still,
Warnings found Drupal core update status No update data available No update information available. Run cron or check manually.