in a first approach I had tried to copy the files directly, but there are too many dependencies, not only the modules, but also what is found in the extension folder and probably in other folders. the result was a general malfunction in several modules, not only errors that I gradually resolved (long process), but even without explicit errors, the modules did not work as they should have.
for this reason, having seen the possibility of exporting custom modules directly, I thought that this solved all the dependencies, but it didn’t import anything and I don’t understand why.
because, as said above, I’m installing the system on a new machine where I don’t have suite, I took the latest version (before 8) directly from the suitecrm site and then I thought I’d pass on the custom modules.
I don’t understand, there is the possibility to “export custom modules”, but it doesn’t work? Is the error mine or the system’s? Is the procedure correct?
I would not be surprised if the export modules function did not work, or if it had limitations that we are not aware of. As you experienced yourself, moving modules can get quite complex, and I just don’t see how that old code can manage it. I don’t think it is often used.
Most people prefer the method of moving files, using source control, etc. Of course, you need to have some notion of what is going on, to solve any problems that arise.
But I really think you should avoid the strategy you’re currently taking. You’re doing what I call a migrate-and-upgrade, which is never a good idea. Your trying to migrate into a different (upgraded version).
Each of the two processes can be complex, so you must try them each on their own, making sure you have a valid system in between the two steps.
install your new system with 7.12.14, migrate the files, validate, then upgrade
back up your old system, then upgrade it to 7.14.12, validate, then migrate to new server
ok, then I’ll try to go back, delete version 7.14.2, install 7.12.14 and try to import the custom modules here, with the procedure described before (I don’t think it works like that either, but I’ll try) and then I’ll do the system upgrade.
two things to ask:
do you know where to find version 7.12.14? on the site I only find upgrade files, but I can’t find an installable version of this version only
I have a doubt, the “export customizable modules” procedure, is it possible that it needs to be performed after exporting the modules? Meaning what:
A. go to “form builder” select my form, export it and then import it into the new system
B. go to Studio, click on export custom modules and import them into the new system.
Is it possible that this is the procedure to adopt?
I can’t vouch for the export/import procedures. I would never use them myself, because I don’t expect them to bring me less trouble than a simple file copy followed by a QR&R. And on the downside, I wouldn’t know exactly what it did, and what it didn’t do.
Also, not that by separating migration from upgrade, you really shoulnd’t have to worry about modules or customizations. The migration won’t break that because you will be moving the entire SuiteCRM directory and the entire database. The upgrade won’t break them because it’s just an upgrade like so many others you’ve done in the past.
That approach is not the best engineering approach and will take up a lot of time for little value - it’s best practise to run some Virtual machine technology on your PC so that you can ran 2 or more different versions as the same time: each with their own code base+database.
They also allow you to create ‘instant snapshots’ - which you can roll back to very easily: which again makes trouble-shooting and experimenting easier.
I wanted to install version 7.12.14 and then pass the custom modules, but it’s not possible because this version only supports PHP up to 8 and PHP 8.2 is installed on my machine.
So I installed the latest version of Suite 7 (7.14.2) after which I followed the procedure described above:
as I thought, you must first export the created modules via module builder, and then import them into the new system; then you have to go to Studio and use “export custom modules” and install these on the new system too.
in this way we will also have the creation of the my_module_cstm tables.
the problem is that extension relations and layoutdefs are not exported, so I will have to manually create the relations and copy the layoutdefs files into the respective folders, unless there is a way to make these procedures automatic.
Hey @ fab, Custom Modules and Module Builder export is not very well documented. I’ve spent a lot of time figuring out the minute details. Here’s a quick summary of how it works:
The Export and Publish options in Module Builder both create a zip file containing the custom module package which can be migrated to another instance.
The Publish option will have the custom module show up in Studio once it is installed. The Export option will have the custom module appear in Module Builder, which will need to be deployed in the instance once it is ready for use.
So, if the module was “Published” and then installed, it will not have the related module builder stuff to be able to export. Also, even if you do have the module builder stuff to export, it’s not current. It’s the original export and does not include any customizations that may have been done in studio. In which case it’s still possible to export, you’d have to do in two steps, first either export or publish the module, then export the customizations from studio.
As mentioned if it was originally installed as “Publish” you wont have the module builder files to export.
Theoretically, you can just copy over the main folder in the core for custom modules and the “custom” folder for the custom module and then run a quick repair and rebuild and everything should be there. (other than the data).
(I’m talking 7, I’ve never done this process in 8 yet)
Hi @dhuntress and @pstevens
so it’s not possible to export all customizations, right? From what I was able to understand.
I exported the modules and then imported them, I then exported the customizations and then imported them, now I have the MY_MODULE and MY_MODULE_cstm tables, from what I understand, to also have the relationships I have to export the tables from the DB (but at this point it is preferable to create them again in Studio), in the same way I don’t have the customizations that I developed in Extension/layout or Extension/vardefs… can you confirm that this is the case or have I misunderstood?
Hey @pgr, 100% agree, that’s what I’d do, copy over everything exactly, including the DB and upgrade in place. However, I think he mentioned in the threads above he only wants “some” of the custom modules to come over to the new installation.
Personally, I’d still move everything over, upgrade in place then delete the unwanted modules.
@pgr as already explained above, I cannot install the same version (7.12.14) on my new machine, because I installed PHP 8.1 and this version of suitecrm supports PHP up to 8.0, so I had to install suite 7.14.2 and therefore I cannot do copying the custom directories and pasting them into the new system, also because I have already done a similar test and there were some modules that did not work as expected, if it were enough to copy and paste the files contained in the Custom/Modules and Extension/Modules directories I would, but evidently suite also creates other dependencies in other directories.
This is not really a strong reason, you can install more than one version of PHP and swithc between them as needed. Much less work, IMHO
These problems are the ones that would be worth figuring out; and no, I don’t think there are other dependencies apart from the one I listed (which are not quite the same that you listed in your reply).
I’m not trying to be a prick, don’t get my tone wrong. I’m just trying to keep things clear in my head. I’m glad you have things working
Hi @fab - I already posted above about Docker and VMware - using a virtualisation/container type tool (there are others) - worth learning - it will save you a lot of time over your future coding career.