Hello all, as the title of the main thread now states: this is solved! I want to thank everyone for taking the time to provide feed back, and for anyone who is interested what follow is how I was able to migrate all of my modules from modules/ to modules/contrib without looking my settings.
As a quick backstory our site was built on a theme that was customized for drupal 7.x, and with EoL coming we needed to upgrade, but the people who did the original site were no longer in business. So I did the upgrade myself an got it all the way up to 10.x with the core being maintained by composer. I came here looking for a solution to moving the modules and adding them to composer as well. The consensus seemed that I was going to have to just uninstall the modules, add them via composer and then go back in and re-create all the customizations. That just seemed asinine to me so I went digging and found several references but not a concise answer.
Through my digging I was able to finally piece together a theory and, through trial and error (ON A BACKUP SITE), I was able to come up with a solutions.
To help illustrate this our site was setup with the following folder structure:
/public_html
|__/portal
|----/core
|----/libraries
|----/modules <== All of our modules are here
|----/profiles
|----/sites
|----/themes
|----/vendors
While I did not try to do them all at once, you might be able to, but I found that I did run into some problems when moving more than one.
Step One: Remove all unused modules. This helped me pair down what I needed to move. After paring them down, here is the list of the modules I needed to address:
- admin_toolbar v3.4.2
- allow_iframed_site v3.0.3
- bg_image_formatter v8.x-1.17
- captcha v2.0.5
- ckeditor v10.2.4
- color v1.0.3
- colorbox v2.0.2
- entity_clone v2.0.0-beta5
- exclude_node_title v8.x-1.4
- flexslider v3.0.0-alpha1
- honeypot v2.1.3
- imce v3.0.12
- libraries v4.0.4
- owlcarousel v3.0.1
- pathauto v8.x-1.12
- quickedit v1.0.3
- rdf v2.1.1
- recaptcha v8.x-3.2
- recaptcha_v3 v2.0.2
- redirect v8.x-1.9
- telephone_formatter v8.x-1.2
- telephone_validation v8.x-2.4
- token v8.x-1.13
- webform v6.2.2
Step Two:
$ cd /public_html/portal/modules
$ mkdir contrib
Step Three:
$ mv <module_name> ./contrib/
Step Four:
$ ../drush cr && ../drush updb
Step Five:
Repeat from "Step Two" until all modules have been migrated
This seems simple enough, right? Wrong. Here's the problem, when you clear the cache I ran into an issue where I would refresh the page and would get tons of errors or a simple "there was an error" message. My guess is that there was something that was still refreshing in the background. I beat my head against the wall as there was not a "this time" that saw it finished. I tried to wait 30, 60, 120 seconds and kept getting those errors.
In the end I created a little php script that executed my drush commands and then had a timer which kept me from doing things too fast. Here is the simple script I put together to make myself wait:
<?php
echo " \033[38;5;0;48;5;11;1m[notices]\033[0m Running drush commands: clear cache and update db then waiting";
echo " \033[48;5;90;1m[running]\033[0m drush clear cache\n";
exec('/var/www/domain.com/public_html/portal2/drush cr');
echo " \033[48;5;90;1m[running]\033[0m drush update database\n";
exec('/var/www/domain.com/public_html/portal2/drush updb');
echo " \033[48;5;125;1m[warning]\033[0m Do not refresh site pages yet!\n";
sleep(300);
echo " \033[48;5;22;1m[success]\033[0m Safe to refresh site pages!\n";
?>
Yes, that is 300 seconds ... 5 minutes. This was what I finally it finally took before I no longer ran into any issues.
Step Six: Add each module into composer using the following:
composer require 'drupal/<module_name>:^x.xx' <ENTER>
Step Seven: Updated Drupal
composer update "drupal/core-*" --with-all-dependencies
Step Eight: Ran my little script again and waited 5 minutes
php -f ~/scripts/portal2_drush.php
Step Nine: Reverified that the site still worked.
YAY! It worked!
Was running my little script to drush cr && drush updb each time necessary? I honestly don't know; however, I do know before I forced myself to do each module one at a time I ws constantly having issues.
That's how I was able to migrate the whole site, modules and all, from a non-composer to a composer managed instance.
OH, also, in /libraries/ I did run into an issue with owlcaracul2. It requires the DOMPurify "data" folder, but when you put /libraries/owlcaracul2/DOMPurify in there it still failed to see the data drive; however, when I mv'd it to dompurify it suddenly recognized it.
Anyway, completely off topic. But, I hope this helps someone later on down the road!
Thanks, and don't forget to tip your waitress!
Jason
the "biggest problem" is all the custom settings in all the modules. When it is "uninstalled" all those are lost, and I'll have to re-install them manually and make all the configuration changes again. And I cannot even take an backup and restore the settings because the module install paths will differ.
I was afraid that was going to be the case. Luckily I have my own servers so I can setup a second site and use it to slowly perform that migration.
However this does bring up another question .... Right now composer is putting the "required" modules in modules/contrib, can this be updated to be in just modules/? I ask because that would solve the biggest problem I have of them being in different directories.
Just a thought.
Thanks,
Jason
@wombatbuddy, Thank you so much!
That is the most succinct and accurate response I've ever had. THank you again!
The picture wasn't uploaded and when I was looking at how to upload it I got called away.
THanks again!
-J
So, it turns out I was missing an entire content view that handled the side bar. Complete bone headed, idioticly stupidly simple mistake.
It does work, and now I'm going to go pound my head against the desk.
I can confirm that I have
).
I also do not have the "Limit allowed HTML tags and correct faulty HTML" enabled, yet I am still not able to set a class id an
Drupal Core Version: 10.2.4
Hey all, so I've just updated an early 8.x and was running into issues where composer was not recognizing the patch.
I tried it on both versions 8.x-2.0 and 3.0.1, and neither would apply the patch. That said I went in and replaced lines 110 - 120 with the (+) of the patch and it worked after the update.
For some reason it did not do the update for the "reviewed & tested by the community" on my last comment.
To reiterate, the installation of the patch (at least on fedora based systems) resolves the issues.
Jason
@Stizzi is correct, and his suggestion did correct the issue. By running sudo dnf install -y patch the issue was resolved and I was able to run both commands.
Now i'm just working to resolve the issue of a timeout!
Thank you @Stizzi.
I am getting this issue as well.
I am attempting to install Commerce Kickstart from scratch using the following commands:
$ composer create-project -s dev centarro/commerce-kickstart-project portal4 --ignore-platform-req=php <-- ignore is due to square/square having a php requirement of up to 8.2 and i'm running 8.2.12 -->
it starts the install and at the end of this I receive the following error for "Applying patches for drupal/bootstrap_basic_image_gallery"
Could not apply patch! Skipping. The error was: cannot apply patch https://www.drupal.org/files/issues/2023-06-01/3363948-3.patch → in pathces.php line 331: cannot apply patch #3363948 - Fix D10 compatibility issues ...
$ cd portal4
$ composer require drupal/commerce_demo:^3.0 --ignore-platform-req=php <-- same reason as above -->
it starts the install and again at the end i get the same error as above stating it cannot install the patch.
Then when i visit domain.com/portal4/web/ i only get the file listing when I then try to go to domain.com/portal4/web/core/install.php i get a 500 error.
When i compare a default drupal composer install to the kickstart one, there seems to be quite a few files missing and I have a feeling it is due to the error not applying the patch and killing the install. OR am i missing something here?
Thank you gisle, i wasn't quite sure there because just above this is the section for the "public file path" and it is set as:
# $settings['file_public_path'] = 'sites/default/files';
Since it is working and shows that as my "public files" I am going to assume it is kind of a default and this is an override.
Thank you again,
-Jason
I have not really used drupal since the early 7.x years, so there are a lot of new features, and this whole patching thing is one. So this is going to be a very, very stupid question to most... if not all.
I'm running drupal 10.1.4, and really just would like to know how do we actually apply the patch?
I've googled "apply patch drupal" but there are no concise instructions that I have found.
I really appreciate the response.
Thank you in advance,
Jason