The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.
By Pahkis on
Hi,
I have manually installed Opigno 2 LMS on Drupal 8 shared hosting using c-panel and softaculous.
I added a substantial collection of contrib modules and libraries from a previous test site to minimise development work.
The inbuilt drupal/composer is working fine, having installed a number of new contrib modules and completed several updates to new versions of the existing modules, both Opigno LMS (profile/distribution) and the contrib modules.
So far so good!
Now I am prompted that drupal 8 core needs updating for a security fix, for which, I have read all the user guides having previously done the same for a Drupal 7 site without any problems. It seems though that Drupal 8, far from making these processes simpler, has in fact made them more difficult and problematic. E.g.:
1. Composerize is not yet ready to handle more complex sites with patches and profiles (distributions) included, so everything has to be handled manually for now.
2. I read the drupal guide at: https://www.drupal.org/docs/8/update/update-core-manually and found the the section on settings.php to make no logical sense at all. I can only assume it is meant to read the same as is done with Drupal 7, I.e. - backup, recreate and modify for custom settings based on backup contents.
3. Both these instructions and those at User Guide: https://www.drupal.org/docs/user_guide/en/security-update-core.html fail to address the issue of what to do if you have any contrib modules downloaded.
Main issue
The main problem is #3 in which we are instructed to remove the core, vendor and other root directory files in order to replace them with the new ones. In so doing, we lose all the info in .json and the vendor sub-directory in relation to our contrib modules. I cannot composerize them afterwards, so does this mean I have to go and retype them all back into the .json file manually!?
Minor Issues
1. Instructions about changing the $settings[update_free_access] variable in settings.php file from false to true and back again, and, although I remember having to change the file permissions in order to edit it, this left me somewhat unsure. They talk about the admin interface, but surely not the one within drupal application as I interpreted it. Presumably they mean c-panel for which I have ownership permissions. Presumably I do not have to worry about this little extra step?
2. Instructions say to disable all Cache such as memcache and varnish. I do not have either of these installed at this time, only the internal page caches installed with drupal core. I presume these also have to be disabled temporarily?
Looking forward to hearing from someone :-)
Kr,
Chris
Comments
Sounds like a poor understanding problem.
Updating Drupal Core should be as easy as: composer require drupal/core:~8.6.5
This assumes there is nothing that prevents that update. Just ran this on a clean installation and it showed some errors. Unfortunately, couldn't trace back those errors. Ran with -vvv, it produced too much output to scroll back. Suspect the patches to be the issue, but on't know for sure. Obviously, patches are patch release depending, but cweagans/composer-patches doesn't support that. That means you need to figure that out yourself. Even with version constrained patches you would have needed to extend them, assuming they would have an appropriate upper limit.
Would consider this a small bug in the distribution: 8.6.4 instead of ~8.6.4.
Or ^8.6.4, depending on your update policy. This would allow you to use: composer update drupal/core --with-dependencies
Composed
Hi,
Thanks for the morale boost ;)
My Understanding is certainly weak, not being a techie, but I have read all the official user and community guides that do not appear to be consistent, some containing some extra steps at the command line or C-Panel file manager levels (changing settings from False to True and then back again), and some 'unclear language' issues relating to back-up and manual replacement of custom settings in the default.settings.php and settings.php files afterwards. I have seen three different versions of the required procedures! This may all seem simple to a techie who has spent their entire working life studying and playing around with these things, but certainly is not simple and straightforward to lay site builders such as myself.
I am not a techie, just a qualified higher-education teacher (with IT project management training and experience) trained in such things, so I only understand them as they actually read. My uncertainty and hesitation should, therefore, be 'understandable'.
I ran composer from shh command line as you suggested
Composer, being the one packaged with drupal 8 and contained in the Opigno LMS zip file (as previously mentioned) I manually downloaded and installed, did not find any available updates as indicated by the status report within the application. Nor did it find any dependencies to prevent an update.
It ignored the update command.
NOt so, surprising given that the update status reports said that a manual update is required.
This means manually deleting the top level files, core and vendor directories - in the process losing all the contrib module download and update information stored there currently. These, I would have assumed, have to be replaced by manually copy-pasting from a back-up of the .json file at the very least.
If you can help relieve any of my anxiety as to the correct procedure, I would be most grateful :)Kr,
Chris
That is not what should happen.
composer outdated drupal/* should report at least drupal/core. The requirement is set to 8.6.4 in the original set up.
composer prohibits drupal/core:8.6.7 should report the opigno package itself due to drupal/core:8.6.4
composer update drupal/core --with-dependencies doesn't update anything because it already installed drupal/core:8.6.4. If it started with 8.6.3 it would update to 8.6.4. To update to 8.6.7 it would require at least drupal/core:~8.6.4.
You shouldn't update drupal/core manually unless you abandon composer. The Opigno LMS distribution is created with composer in mind, which means you need to use composer to manage existing code. Manually do what composer does for you is not feasible. You would need to merge composer.json composer.lock and vendor, that is what composer is for.
The manual update in the update status report is about non composer managed code bases. It should be ignored apart from the update information itself. You should use composer for updating the code base.