Hi,
I installed suitecrm 7.14.2 on a new machine, now I would like to export my custom modules from an old machine on which suitecrm 7.12.14 is installed, what is the correct procedure?
I went to Studio and clicked on âexport customizationsâ, I selected all the indicated modules and created the .zip file.
Then I went to module loader and installed the package, but nothing happens, everything was fine, no errors, but the modules were not installed, not even after a quick repair.
The module tables are not present in the DB, but only the connection tables between the customized modules (modules A and B are not present, but table A_B_1_c is present).
Where am I wrong? Is the procedure I followed correct? Thank you.
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.
So, eitherâŚ
install your new system with 7.12.14, migrate the files, validate, then upgrade
or
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.
update:
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.
I have notes on how to migrate from 7 > 8 while retaining all custom fields in studio etc - Iâll dig them up for you and make them legible - thereâs a couple of database tables dependant.
You are correct, into studio and export the module on old suite - Then import the module into the new suite
copy over the DB table fields_meta_data and you should be golden to import your records - suite will then put them in.
Youâll then have to export the specific tables that contain your data relationship links - f.ex contacts and cases
You import contacts first, then import cases - do this through the front end!! not the database.
You open a contact and thereâs no case there.
Export the db table - contacts_cases and import to your new suite database - this then puts the relationships back.
Same principle for the other modules, accounts and contacts, thereâs an accounts_contacts table, etc etc etc
From memory this should give you a headstart - Iâm available on discord if you need a 1-1 helper just send me a PM
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?
What exactly are the downsides of a full copy from the file-system?
Copy the custom dir, and any custom modules under modules dir.
Do it between systems at exactly the same version. I know, people want to skip this clause, but really, donât; just leave upgrading for a moment when youâre not migrating, theyâre two separate things
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.