Custom module logic without using the "/custom" folder

👨‍💻 Development Help
1

Hello, I am creating a new module and I need to write some hooks to execute some code in some cases, for example, by deleting a relationship with another module, or by deleting a record.

I would like to keep all the files of my module in its own folder, without using /custom. I do not want to use logic_hooks in /custom/…

I know I can include my code when saving using the save() function in the file /modules//.php but I do not know how to do it in other types of hooks or events.


/**
 * THIS CLASS IS FOR DEVELOPERS TO MAKE CUSTOMIZATIONS IN
 */

class <mymodule> extends <mymodule>_sugar {
	var $importable = true;
	function <mymodule>(){
		parent::<mymodule>_sugar();
	}

	public function save($check_notify = false)
	{
	// my own code.....
	parent::save($check_notify);
	}
}

How can I write here the code equivalent to a logic_hook like after_relationship_delete or before_delete (for example)?

Do you know if this can be done and how?

thank you!!

2

I really wouldn’t recommend this. There are many places in SuiteCRM code and installers that make decisions based on the know directory structure. It’s really not a good idea to do it differently, and it might not be possible at all in some cases.

Why don’t you want to use custom dir?

3

Hello, pgr

We are creating some modules to distribute in different installations of SuiteCRM, and after that, they will have their own modifications in the folder /custom.

We would like to ensure that all the logic of the module remains intact in the module’s own folder. Maybe other programmers include (in each installation) some logic_hooks, but these should not overwrite the behavior written in the module itself (out of /custom).

Many original modules of SuiteCRM/SugarCRM, include this type of functions in their own folder.
Is it not possible to do this same, safely, in newly built modules?

Thanks!!

4

The custom folder is designed to assemble contributions from different sources orderly. So it is expected that some code there comes from Studio, some from imported modules, some from PHP customizations using the Extension mechanism.

This has some complexities, but it works and is documented (though in several places, not in a single source, so some parts might be hard to figure out at first).

You can use a nice structure under the “custom” dir to keep things tidy, but other than that… I would stick to the normal scheme.

What most people do in practice nowadays is use Git for source-control and just merge in all the changes (which might involve several different directories) when applying a module.

5

Ok prg, vamos a escuchar tu recomendaciĂłn
¡Muchas gracias!