Problem/Motivation
my D11 site is composer installed/managed,
drush status | grep -i version
Drupal version : 11.1.0
PHP version : 8.4.2
Drush version : 13.3.3.0
served up on a linux instance of nginx/1.27.3.
it's got a few added modules installed, and some dummy content populating it.
so, a real-world use case, but not a _large_ install by any stretch.
as advised here
https://www.drupal.org/docs/develop/core-modules-and-themes/core-modules...
"If you installed Drupal with Composer, you will need to update with Composer (https://www.drupal.org/docs/develop/using-composer/manage-dependencies)"
all good, that's the goal; `update_manager` module is DISabled.
but, a site status check reports:
"Update notifications are not enabled. It is highly recommended that you install the Update Manager module from the module administration page in order to stay up-to-date on new releases. For more information, Update status handbook page."
the site _seems_ to be behaving without it through install and inital use.
until _after_ i enable update_manager.
enabling is fine; but subsequently any site access sees this FATAL error:
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).
Drupal\update\ProjectCoreCompatibility->__construct(Array, Array, Array) (Line: 106)
update_calculate_project_data(Array) (Line: 40)
update_requirements('runtime')
call_user_func_array('\update_requirements', Array) (Line: 355)
Drupal\Core\Extension\ModuleHandler->{closure:Drupal\Core\Extension\ModuleHandler::invokeAll():354}('\update_requirements', 'update') (Line: 307)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('requirements', Object) (Line: 354)
Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array) (Line: 109)
Drupal\system\SystemManager->listRequirements() (Line: 93)
Drupal\system\SystemManager->checkRequirements() (Line: 122)
Drupal\system\Controller\SystemController->overview('system.admin_config')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::wrapControllerExecutionInRenderContext():121}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::onController():96}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 709)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
simply DISabling (drush pm:uninstall udpate) fixes the issue, and the site's immediately accessible & functional as before.
i suspect (?), but don't yet know, this is due to php version 8.4.2, which i understand Drupal is NOT compatible with.
yet.
but IS on the roadmap.
there's not specific indication of a php problem -- that i've found so far.
not sure if this
Hide and restrict package_manager (and update_manager) behind a dev/prod toggle so that they can be alpha stability in tagged releases
https://www.drupal.org/project/drupal/issues/3483481
includes an option to disable the complaint (?).
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3495587
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
cilefen commentedI think this may duplicate #3135663: Update manager compatibility logic is missing if you're on a -dev release of core or #3467538: Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\update\ProjectCoreCompatibility->getPossibleCoreUpdateVersions. It looks like you commented on one of them. Is this issue distinct?
Comment #3
pgndrupal commentedre: 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).
atm, in my current state, _this_ is fully repeatable/reproducible, here.
dunno what specific info's helpful; can grab if asked.
Comment #4
cilefen commentedThis, I think is the same error as #3495587: TypeError: Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\update\ProjectCoreCompatibility->getPossibleCoreUpdateVersions when enabling this module. #3495587: TypeError: Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\update\ProjectCoreCompatibility->getPossibleCoreUpdateVersions when enabling this module 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.
Comment #5
pgndrupal commented@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?
Comment #6
cilefen commentedI am seeking to understand if this issue duplicates the previously-reported #3467538: Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty in Drupal\update\ProjectCoreCompatibility->getPossibleCoreUpdateVersions. 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.Comment #7
pgndrupal commented> 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.
Comment #8
cilefen commentedAre there contributed or custom modules present in the Drupal installation that produces this bug?
Comment #9
pgndrupal commentedyes, there are.
no, i've not been able to bisect.
fwiw, in this specific instance here:
with _that_ simply enabling `udpate` causes the error.
the only logs i've seen, i've shared.
Comment #10
cilefen commentedAt a glance it may be composer_deploy, because it modifies update information. I would try uninstalling it first.
Comment #11
pgndrupal commentedit was already happening prior to `composer_deploy` installation; i'd installed that while attempting to deal with this.
that said, specifically,
and, immediately, at nav to `https://example.com/admin/config`
Comment #12
cilefen commentedIs it still the case when the module code is not present? Update manager looks at all present extensions.
Comment #13
cilefen commentedFor 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...
Comment #14
pgndrupal commentedas above
*AND*
now, NO WSOD error at /admin/*; poking around the site, can't atm get it to replicate.
if not a fluke, `drush pm:uninstall composer_deploy` does not seem sufficient?
also, now, checking status report @ https://example.com/admin/reports/status#warning ,
1 warning
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
Comment #15
godotislateThe 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: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:
So in ProjectCoreCompatibility, it could look something like:
Alternatively, probably should consider enforcing
versionto be a string (making it translatable doesn't make much sense IMHO), sochanging
$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.Comment #16
godotislateComment #18
godotislateFor 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.
Comment #19
pgndrupal commentedfwiw, confirming
no more FATAL error, so far. the two mods can coexist.
@ status report, i DO see now/still,
Comment #20
cilefen commented"No update information available" is a separate matter. There is a large volume of posts online about that dating back many years. The causes can vary, but include issues such as an inability of the initiating process to access the updates domain via HTTP, occasional minor outages of the updates feed, and other reasons. It should be investigated with those resources instead of here.
Is it now established that the cause is composer_deploy? The
existing_versionstring being translatable doesn't actually make sense so if "yes" we should probably move this issue to that project's queue.Comment #21
pgndrupal commented> separate matter
+1
> move this issue
i'm fairly sure -- not 100% -- i've seen these TypeErrors crop up elsewhere, before i composer installed composer_deploy.
but i've been only been able to reproduce it reliably in this case.
the 'hardening fix' in #15 appears to work in this case -- but appears more general.
if the fix _is_ sane, shouldn't it be applied in core, not 'just' in composer_deploy?
Comment #22
cilefen commentedSure but I have to ask: What is the use-case for a version string being translatable markup? It seems like a mistake.
Take, for example, this code from the
package_managermodule:Comment #23
pgndrupal commented> what is the use-case
ok, i'm the wrong person to comment -- too new to speak to Drupal-at-large.
best i can confirm is that the MR workaround works, in this case, to solve the coexistence of update and composer_deploy.
whether that's the _right_ fix, got me atm; @godotislate would be a more reliable source. and, whether or not this moves to module queue ...
if the same/similar _error_ surfaces here under difference circumstances, i'll add/open as needed.
EDIT
fwiw, i've gotten two reports from others -- a bit stale now -- of TypeErrors with use of `dotenv` module.
i'll see if i can dig up more re: the specifics; i use `vlucas/phpdotenv` instead, so can't say yay/nay for my local install.
Comment #24
pgndrupal commentedon a new iteration of D11 install, with fewer overall added modules,
in particular
@ nav to:
https://example.com/admin/config
now get another TypeError, tho different,
repeating
cures it locally, again.
nav to:
https://example.com/admin/config
works fine.
Comment #25
cilefen commentedComment #26
pgndrupal commented@cliefen
i note your reassignment.
fyi, now on another install, with NO attempt to install composer_deploy at all
it's again on an early stage install. don't yet know WHY it's occurring, but can say -- on this instance -- there's NO composer_deploy.
i simply don't know what the cause is. `composer_deploy` is reproducibly involved with the issue.
but does NOT seem to be the sole module in play here ....
Comment #27
pgndrupal commentedfyi, yet another instance, different module,
https://www.drupal.org/project/redis/issues/3496126
Comment #28
cilefen commentedComment #29
cilefen commentedComment #30
cilefen commentedThis happens with or without contributed modules but the reproduction steps remain a bit unclear. We need technically-detailed evidence of the root cause. If that cause is definitively the composer_deploy module based on evidence, ideally including debugging function parameter data, please move this issue back there.
Comment #31
pgndrupal commentedatm, still with php 8.4, the following reproduces a "TypeError: Cannot access offset of type Drupal\Core\StringTranslation\TranslatableMarkup in isset or empty ..." error -- here.
and, yes, i understand that this may _still_ not be 'vanilla' enough :-/
just reporting atm; test with php 8.3 in on my ToDo list ...
@ login/nav to --> https://example.com/admin/config/
FAILs, with similar error as reported
Comment #32
dwwDisclaimer: it's a bug in update.module* that the error case for an unknown version string ends up as a fatal error. We should probably fix that, regardless of why your site has no version info for core.
Meanwhile, the most useful things for me to understand this would be:
core/modules/node/node.info.ymlon the site where this is happeningVERSIONconst fromcore/lib/Drupal.phpLooking at the output posted above, I notice:
composer require drupal/redis:dev-1.xWhich means you're asking for a "dev tarball". For that case, I'd also love to see:
modules/contrib/redis/redis.info.ymlmodules/contrib/redis/.gitexists. Is it a git checkout?To add another variable to the mix, if you're using a Git checkout of any part of Drupal (core or contrib), you need to use git_deploy for
update.moduleto work. I'm less familiar withcomposer_deploy.Comment #33
cilefen commentedI don't understand the unknown string angle. It's a type error where the type is
Drupal\Core\StringTranslation\TranslatableMarkup, and objects can't be array indexes (aka "offsets").Comment #34
dwwSee comment #15. It’s being set to the translatable string “Unknown” but then being treated like an actual version string, which we fail to parse.
Comment #35
cilefen commentedUnderstood. Thank you for that clarification.
Comment #36
pgndrupal commented@dww
in reply to #32
> ... bug in update.module* that ... should probably fix that ...
need a separate bug for that? any specific info that helps?
> The entire contents of core/modules/node/node.info.yml on the site where this is happening
> The VERSION const from core/lib/Drupal.php
> Looking at the output posted above, I notice:
just to remind, i don't see these TypeError messages only with redis.
> composer require drupal/redis:dev-1.x
yes. specifically
where
https://git.drupalcode.org/project/redis/-/commit/c53812040dd4ccec95d75b...
solves
https://www.drupal.org/project/redis/issues/3494308
> The entire contents of modules/contrib/redis/redis.info.yml
> If modules/contrib/redis/.git exists.
it does,
> Is it a git checkout?
i did not check it out; simply installed with
> if you're using a Git checkout of any part of Drupal (core or contrib)
i do not. the project was composer-created, with '--remove-vcs' opt, all modules are composer/drush managed, and i have not yet init'd git for my own vcs at this stage.
> you need to use git_deploy for update.module to work. I'm less familiar with composer_deploy.
my initial understanding was that composer_deploy was to be used in a composer-managed install.
i tried it initially, only to bump into the TypeError again with that module.
Comment #37
pgndrupal commentedthis is about as simple a reproducer as i'll manage here.
i can generate a similar FAIL reliably, below.
*NO* additional modules are required.
simply disabling `automated_cron`, so as to use external cron, is sufficient.
nav to:
https://example.com/admin/config/
GOOD
simply DISABLE (uninstall) `automated_cron`
nav to:
https://example.com/admin/config/
FAIL, with
Comment #38
pgndrupal commentedrepeating same procedure from scratch, but with php 8.4 -> 8.3,
still FAILs, as above,
Comment #39
pgndrupal commentednav to .../admin/config
on one of many similar ERROR
@
EDIT core/modules/update/src/ProjectCoreCompatibility.php
re-nav to .../admin/config
ERROR
@
in both cases, an issue with an `existing` version check
back to EDIT core/modules/update/src/ProjectCoreCompatibility.php
at nav to,
Comment #40
smustgrave commentedSeems like this probably needs to be re-opened.
Comment #41
quietone commentedAfter reading the issue summary I learned that this occurs on "Drupal version : 11.1.0" and 'PHP 8.4'. The PHP requirements page shows that Drupal 11.1.0 is not compatible with PHP 8.4.
I tested with 11.x today and PHP 8.3 and did not get any errors. But that was using a git clone of core.
Tagging for an issue summary update to help reviewers.
Comment #42
pgndrupal commented@quietone
>> The PHP requirements page shows that Drupal 11.1.0 is not compatible with PHP 8.4.
no,
@
"PHP requirements"
https://www.drupal.org/docs/getting-started/system-requirements/php-requ...
specifically states PHP v8.4 *is* supported with Drupal 11.1,
--> https://i.imgur.com/K0WNrW2.png
and that
" ...
Drupal will work on all supported PHP versions.
..."
Comment #43
szato commentedWe got the same error.
We are using custom PHP images (8.3) with apcu. We were using apc.serializer=igbinary, if we changed to apc.serializer=php the errors went away.
Comment #44
eduardo morales albertiRelated error on smart_trim 2.3.1 https://www.drupal.org/project/smart_trim/issues/3566575#comment-16414753 due to plugin definition
The solution, all plugin properties should be translatable or at least, the label on \Drupal\Core\Entity\EntityFieldManager::getFieldLabels
But there are more fields that are affected, like the category on some modules https://git.drupalcode.org/project/butils/-/commit/b9a19526f68975f389c11...