Problem migrating instance

📦 Install & Upgrade Help
1

Hello all,

After we make a migration from one machine to another, for the same instance, some of the configuration files doesn’t work any more or they are not fully processed. In our case it is a custom vardef.php used in Custom/modules/Tasks.

The executed process was based on the following instructions:

http://support.sugarcrm.com/Knowledge_Base/Platform_Management/Moving_Sugar_to_Another_Server/

We have extracted the DB and the file system to another machine, restored the DB, in the new machine, and executed a Quick Build and Repair.

Unfortunately the problem still exist.

Can anyone help us with this problem? Is there any configuration file that we should change to execute de Build and Repair, rather than config.php (that we change to point to the new DB location)?

The objective of this customization is to add the Reminder panel in Task views. After we have migrate and upgrade with fully success, We will share the process started on the following topic:

https://suitecrm.com/forum/developer-help/16798-how-to-add-the-remainder-panel-in-the-task-edit-view

Thanks in advance,
JoĂŁo Rebelo Pinto Gomes

2

I don’t know, but a couple of things people often overlook, and that you can check:

  1. After a Quick Repair and Rebuild, scroll down to the bottom: if there is a button there to sync database to vardefs, press it.

  2. There is a table in the database called fields_metadata which contains information about fields; when migrating the full DB, this is also be moved to new the instance. Check if that is what’s intended - or if that is what’s missing.

3

Hi pgr,

We move the file to custom extension, not the custom/module and it resolves the issue.

We still have a problem on migrating, because we have a custom Task.php and we cannot find a safe upgrade location for it.

Regards,
JoĂŁo

4

It doesn’t look like that particular file is ready to be customized in an upgrade-safe way. The references I find to it are these:


/var/www/html/modules/iCals/iCal.php:381:            require_once('modules/Tasks/Task.php');
/var/www/html/include/modules.php:185:$beanFiles['Task'] = 'modules/Tasks/Task.php';
/var/www/html/include/Smarty/plugins/modifier.default_date_value.php:27:- modules/Tasks/Task.php
/var/www/html/include/utils.php:2595:        'Tasks' => 'modules/Tasks/Task.php',

You can try changing them in a similar way to what is done here for another module
https://github.com/salesagility/SuiteCRM/pull/3891/files

But those 4 references above look like quite different things and I’m not sure it can be done for some of them…

If you can confirm it works out fine we can push those changes into the main code.

5

Hello,

So, just to be sure that I understand the idea.

For those 4 references I should create an if clause to check if a custom file exists. is that right?

If I am right, another question comes to my mind: If I change those files, are those changes safe upgrade?

Another way that comes to my mind is the if we customize the controller, the one which calls the module’s model, and put it on the extension framework, does this closes the issue?

Thanks,
JoĂŁo

6

You don’t need an if clause because the function get_custom_file_if_exists already does that (see the PR I linked).

If you change those files, those changes are not upgrade-safe, that’s why I mentioned integrating those changes into the main product - that way they become upgrade-safe, and enable other users to do the same customizations.

If you can get the same results by extending a class and it gets picked up from the custom directory, then you don’t need any other mechanism., correct.

7

Hi!

If I have understand well, the code in the link is sugesting that for each bean that we would to extend, the folloing line should be inserted:

require_once(get_custom_file_if_exists(‘modules//.php’));

I think this is not a good solution because we are replicating the same code for all the beans. Instead, if we had, like it has in case of extending a controller, a place to verify if a bean has a custom file or not, it would be much more efficient.

Exemple -> include/MVC/Controller/ControllerFactory.php

static function getController($module){
$class = ucfirst($module).‘Controller’;
$customClass = ‘Custom’ . $class;
if(file_exists(‘custom/modules/’.$module.’/controller.php’)){
$customClass = ‘Custom’ . $class;
require_once(‘custom/modules/’.$module.’/controller.php’);
if(class_exists($customClass)){
$controller = new $customClass();
}else if(class_exists($class)){
$controller = new $class();
}
}elseif(file_exists(‘modules/’.$module.’/controller.php’)){
require_once(‘modules/’.$module.’/controller.php’);
if(class_exists($customClass)){
$controller = new $customClass();
}else if(class_exists($class)){
$controller = new $class();
}
}else{
if(file_exists(‘custom/include/MVC/Controller/SugarController.php’)){
require_once(‘custom/include/MVC/Controller/SugarController.php’);
}
if(class_exists(‘CustomSugarController’)){
$controller = new CustomSugarController();
}else{
$controller = new SugarController();
}
}
//setup the controller
$controller->setup($module);
return $controller;
}

I think this should be the same logic for bean extend. I just not found the right place yet.

Don’t you agree?

8

I don’t have time now to consider any such big changes… you’re right, of course, that generic mechanisms are better, but I feel that if you really “dived” into this issue you would find 95% of such generic mechanisms are already in place.

What I can say is that whenever I find one specific file I can’t customize in an upgrade-safe manner, I try to fix the way it’s being loaded. In your case, I would say you can simply try these changes:


modules/iCals/iCal.php:381:            require_once(get_custom_file_if_exists('modules/Tasks/Task.php'));

And tracking that other variable I would add this:


modules/Tasks/Task.php:209:               require_once(get_custom_file_if_exists($beanFiles[$beanType]));

Then try your customization to see if it gets picked up. If so, we can fix this easily in main SuiteCRM.

For the bigger vision you have, if you really conclude it’s necessary, you’d have to work it over and propose it on GitHub to the project leads.

9

I understand your point of view pgr, however I would prefer to take a little more time and get a cleaner solution :wink:

Hope I can find a way and help others with this kind of featuers.

1 Like
10

That attitude is exactly what this project needs, I am with you on this one.

But I still think my changes are worth taking seriously, even if any other larger fix is attempted. So if you can please test them I would like to put them into the product anyway.

The reason I don’t look at this as a “dirty hack” is that there is a consistency here. Every part of the code already works like that. Sure, that means the mechanism is used in hundreds of places, yes, but they are already there, it’s almost done. And since it’s a key characteristic of the product, and one that every add-on and every customization relies on, it’s really not likely to change anytime soon.

Basically, as a convention, SuiteCRM is supposed to use get_custom_file_if_exists or a similar logic every time it “requires” or “includes” something. We should keep striving to make that convention complete across the product, even if we then have other efforts to reduce code repetition (with all the problems it generates) by doing more generic fixes like you suggest.

Thanks for your contribution and your thoughts on this - I hope I defended my case, without attacking yours :slight_smile: