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).
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. (Note, later versions of Jomres plugins will not include a constructor called something like j0005dick as this isn't compatible with PHP7, however you may be working on older files that do retain this structure)
- 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 Overrides feature.
- 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.