Here we will discuss ways that you can modify Jomres to suit your own requirements.
Jomres, whilst it works fine 'out of the box' should nevertheless be seen as a toolkit. It has been designed to be easily edited by everybody from your basic designer who's strengths are layout and design only, the part-time coder who can modify a few lines of code to achieve what they want, to the full developer who wants to build plugins either to extend their system or offer plugins to other users (either for free for for a fee).
We will losely group the different articles into three categories :
These three groups should not necessarily be considered in isolation. For example, if you want to add a new field to a form, you'll need to understand both the editing code and editing templates principles in Jomres, however if all you want to do is change some layout then the editing templates section will probably suffice.
So, you want to modify how Jomres works? Before you do, read this :
If you would like to edit some of the core Jomres functionality, for a large part this can be done easily in a way that is upgrade safe (i.e. will not be overwritten by an upgrade of Jomres). Many techniques are discussed at length in
other manual pages, but to summarise :
-
If you want to customise a file with the naming pattern of
jnnnnnxxxxx.class.php you can do so by first copying it to a /jomres/remote_plugins/xxxxx (e.g. /jomres/remote_plugins/custom_code) subfolder and then using the "Rebuild Registry" feature in the administrator area of Jomres. When you do this Jomres will use the copied file, instead of the one in the /jomres/core-minicomponents directory, so you can edit that file at your leisure. Jomres will not overwrite this copy of that file when you
upgrade.
-
If you rename a Jomres minicomponent, to modify it's functionality, it's important to not only rename the file. For example if you have a minicomponent called j00005tom.class.php, and you want to rename it to j00005dick.class.php, you must also change the class name and the constructor to j00005dick too, in the file itself.
-
If you want to copy a minicomponent (for example so that you've got a backup while you edit another version of that file) do not simply rename it to something like j00005harry_backup.class.php. Instead rename it to xj00005harry.class.php, otherwise Jomres will try to run that script as it follows the naming pattern it's expecting, and this could result in unpredictable behaviour.
-
If you want to customise one of the classes found in /jomres/libraries/jomres/classes, then again first copy it to a /jomres/remote_plugins/xxxxx subdirectory (no need to rebuild the registry). Jomres' class import functionality will use that instead so you should make changes to that copy, not the original. Jomres will not overwrite this copy of that file when you upgrade.
-
If you want to change any of the Jomres template files, we strongly advise you to use the
Template Editing feature. By doing so, your changes are saved to the database, instead of the files on the server's disk. This way, if you make a mistake in your template changes you need only use the editing feature to remove your customisations and Jomres will revert to using those on disk. Additionally, those changes are not overwritten when you upgrade, whereas the files on the server's disk are overwritten during an upgrade.
-
If you want to change the language strings/lables used, you can edit a
language file, but before you do that we would encourage you to first use the
Label Translations feature. This can be used even if you are not using multiple languages, if you simply want to reword one string from another. Again, changes are saved to the database so if you upgrade, your customisations are not lost. Most, but not all, language strings can be edited through the Label Translations feature.
-
Property types which you have created have their own language files, stored in /jomres/languages/xxxxx (where xxxxx corresponds to your new property type's title). These files are
not overwritten during an upgrade, so you can use this to your advantage too.
In all cases, be aware that if you customise a file, and you upgrade, it is possible that your customisation may not be compatible with the newer version of Jomres. If that should happen and your customisations have introduced an error then we advise you to enable Jomres' Safe Mode (Site configuration -> Debugging tab) to confirm whether or not it's your customisations that've introduced the error before reporting any possible issues to ourselves. We are never responsible for resolving issues generated by your or your developer's code alterations.
If you believe that a customisation you have created has caused a bug you can prove this by setting Jomres' Safe Mode option in Administrator - Jomres - Site Configuration - Debugging to Yes. This will tell Jomres to not use files in /core-plugins or /remote_plugins. If the system then works as Jomres would normally without any plugins, then it's one of your customisations that's causing the problem.
