Problem/Motivation
There seem to be some ongoing issues as a result of this release and it would be really helpful to have a stronger sense of why they are happening. So far it's just "seems to happen for some people, but not others."
Drupal 8.6.6/8.5.9/7.62 sites still trying to update to 8.6.7/8.5.10/7.63
If you updated to 7.62, 8.5.9., or 8.6.6 using Drush, received errors, and then ran into difficulty getting the site updated to the hotfix releases (which some users have reported), try using the
manual update instructions →
to get your site onto a version of Drupal that better supports Drush:
8.6.7 →
,
8.5.10 →
, or
7.63 →
Sites updated to 8.6.7, 8.5.10, or 7.63
If you have upgraded to
8.6.7 →
,
8.5.10 →
, or
7.63 →
and are still affected by the Fatal error: Uncaught TYPO3\PharStreamWrapper\Exception when running Drush commands, can you do a few things. First:
- Ensure the site has been fully updated to the hotfix release by running
update.php and then checking the version on the stats report. If you installed the security releases first, you may see the errors when updating to the newer releases, but it might be fixed afterward.
- Test Drush again after you've verified the site is on one of 8.6.7, 8.5.10, or 7.63.
- If you get errors mentioning
cache_get(), double-check that the new libraries at http://cgit.drupalcode.org/drupal/tree/misc/typo3?h=7.x were correctly deployed to your server.
Then, try some of the following:
- Try upgrading Drush to the most recent version of Drush 8. Drush 8.1.18 reportedly has a fix that helps resolve the issue.
- Try renaming the
drush CLI command file back to drush.phar and create a symlink for drush to that file, i.e.:
mv drush drush.phar ; ln -s drush.phar drush
- Attempt your calls using
drush.phar instead of drush.
- Run
drush cc drush outside of a drupal site root after your code is upgraded.
Links to drush paths are found in drush cache.
🐛
After upgrade to 7.63, 8.5.10, 8.6.7, 9.4.0 get TYPO3 phar error for drush
Fixed
- If you can, install Drush with Composer/upgrade Drush to version 9. (This is more involved as some Drush commands have changed and some have been removed, but it's also likely to completely fix the problem).
- Try replicating the problem with the same codebase/database in different environments - e.g. does it work locally but fail on your hosting provider? Or vice-versa?
- Try replicating the problem with a brand new codebase/database install in the same environment. Does that still cause the problem?
- Take note of the directory paths where Drush and Drupal are installed. Are there symlinks? Is Drupal installed in a subdirectory? Etc.
If you can report with details of where you were before/after and what worked/didn't - that will all be enormously helpful.
Proposed resolution
TBD; we need to determine the exact source of the problem.
Remaining tasks
Needs further triage.
User interface changes
N/A
API changes
TBD
Data model changes
N/A
Release notes snippet
TBD
Original report
Porting from
https://www.drupal.org/project/drupal/issues/3026386#comment-12929709 →
Upgraded to drupal 7.63 and still have this issue. Note in the uploaded screeny I tried drush up drupal for kicks but I already had 7.63 in the repository... Doesn't happen on all my sites on this server using the same drush setup... just this one...
the drush command on this server is an alias to a script that calls the drush.phar. Adding a symlink and calling that via the script does nothing for us. example
which drush
alias drush='sudo -u apache /usr/local/bin/scldrush'
/bin/sudo
scldrush looks like
#!/bin/bash
. /opt/rh/rh-php56/enable
/usr/local/bin/drush "$@"
Where /usr/local/bin/drush is the phar version of drush....
Even following step 3 didn't seem to work here...
What did work was pulling out a composer version of drush... but now I got to get the server admins to get that out there so that cron and the like is using it.
I'm concerned that the way we are looking through the backtrace isn't fool proof. We may want to explore to see if this also allows other phars to slip under the radar is they are good enough to imploy the work around using symlinks?