Composer has a built in override that will bump that to 1.5G in order to install this module, we need to bump the limit up past about 1.6G. See, turns out the memory limit in most php.ini files is about half a Gig. You'd think that the module contributors would catch on to something like this. Let's see what happens: Never mind that the "-dev" option is deprecated PhP FaTaL ErRoR!?!? *smh* $ composer require 'drupal/upgrade_status:^2.0' It looks easy enough: $ composer install -dev
#Drupal vm installation run out of memory upgrade
Unlike most other modules, the Drupal Upgrade Status module can't be installed with Drush it needs to be installed with Composer (the deep state is out to get me-I swear!). I'm not quite ready to troubleshoot the module (I can't even tell which one is the problem), so my next step forward will be to get the Drupal Upgrade Status module installed on the site and see if it can provide some better diagnostic info.
It looks as though I've got a module (or modules) that may not be D9 compatible. Cool! Getting Composer to Play Nice with PHPĪfter getting my VM setup and branching out, I decided to run through the Drupal 9 upgrade instructions at. With the symlink in place, when Composer goes looking for the global PHP version, it will find the version installed under XAMPP. What to run in the command line is in the AskUbuntu link, so I won't bother with it here. in a sense it's just not smart enough to know that my project isn't actually dependent on the global PHP version.ĪskUbuntu to the rescue! The fix is to get a symlink (an alias) pointing one version of PHP to the other. If, at this point, I go run a composer require on my D9 project, Composer will very quickly, in non-ambiguous terms, let me know that the version of PHP I'm running globally is incompatible with whatever I'm doing in D9. So, let's say that at this point I have both XAMPP and Composer installed in my new VM. This is a problem: I'm running 7.2 globally and D9 requires 7.3 Why wouldn't it? Unless you tell it that your project is dependent on the PHP libraries unique to XAMPP, it has every reason to believe you're using the global PHP version (7.2 in my case). Rather, it's about being able to adapt-to roll with the punches, as it were.Īnother quick note: Composer is generally installed globally it's gonna leverage your global PHP version, and not the version you have local to /opt/lampp/bin. Web development isn't really about *mastering* a given toolset toolsets will change. If you ask me, the removal of pm-updatestatus from Drush 10 is a crime against humanity. I resent Drupal for increasingly moving the maintenance of sites into Composer. In an attempt at transparency: I'm a drush kind of guy. Quick note: the global installation of PHP on Ubuntu is found at /usr/local/bin/php (if in doubt, verify your global PHP location with $which php) the local installation of PHP for XAMPP is found at /opt/lampp/bin/php Getting Composer to Play Nice with XAMPP Drupal 9 requires PHP7.3 or later, but since XAMPP can be downloaded with it's own version of PHP, it shouldn't matter that the global installation of PHP on the OS is 7.2. Take note: Ubuntu 18 comes preloaded with a global installation of PHP7.2įastest way to get a LAMP stack up and running on Linux (that I know of) is with XAMPP. As an added bonus, I can do a Ubuntu installation and run it from my Xubuntu host: nice opportunity to look at the two OS'es side by side (diagnosis so far: Xubuntu for the win). Step 1 - let's not muddy the water in my Drupal 8 workflow much better to get a VM up and running, branch out, and keep my local machine safe and sound in the meantime. Time to start testing the water for a Drupal 9 upgrade.
0 kommentar(er)
