Installation

Minimum Requirements

Sie müssen ein funktionierendes CMS haben, in das Sie Jomres installieren können. Standardmäßig unterstützt Jomres Joomla 1.5, aber es kann auch für andere CMS konfiguriert werden.

• PHP 5.2.x oder neuer
• MySQL 5. oder neuer
• Apache 1.13.19 oder neuer
• Eine feste IP. Jomres arbeitet wenn ihr Host einen Proxy nutzt, aber Sie müssen uns kontaktieren um ihre Lizenz zu modifizieren damit unterschiedliche IPs erlaubt sind. Eine shared IP ist prima, solange Sie sich nicht ändert.
• GD muss aktiviet sein.
• Empfohlen 64MB  memory_limit

Jomres arbeitet nicht mit Joomla 1.0.x, da es nicht länger vom Joomla-Projekt-Team unterstützt wird. 

PHP Requirements

Um den vollen Funktionsumfang von Jomres nutzen zu können müssen Sie folgende PHP Features/ Moduleaktiviert haben:

• Socket Funktionen - wird für lizenzierende Produkte/ Kommunikationen mit dem Jomres Lizenz-Server (benötigt). Normal wenn CURL verfügbar ist, ollte dies ausreichen.
• Datei-Stystem-Funktionen - wird zur Sicherung Ihres verschlüsselten Lizenzschlüssel auf der Festplatte und hochladen von Objekt- und Zimmerbilder (benötigt)
• Kalenderfunktionalität - ( die 'gregoriantojd' Funktion). PHP benötigt zur Erstellung --with-calendar Funktion für den ordnungsgemäßen Ablauf. (benötigt)
• Sie müssen sicherstellen, dass Sie MySQL, XML and Zlib Support in PHP integriert haben. (benötigt)
• Sie müssen sicher stellen, dass sie Safe Mode abgeschaltet haben.

Dies ist eine Liste, die sehr viel Abverlang, doch die meisten qualitativ hochwertigen Provider unterstützen standardmäßig in ihren Hostpaketen diese Funktionen.

Wenn ihr Host eine Firewall verwendet, müss für den Lizenz-Server, damit dieser arbeiten kann, sichergestellt werden, das dieser eine Verbindung nach "*.jomres.net" erstellen kann. Wenn Sie den Webinstaller verwenden muss zusätzlich (nötig) eine Regel zu "*.jomres4.net" (beides auf Port 80) geöffnet werden und CURL aktiviert werden falls dies nicht schon geschehen ist.

Installation

Minimum Requirements

Sie müssen ein funktionierendes CMS haben, in das Sie Jomres installieren können. Standardmäßig unterstützt Jomres Joomla 1.5, aber es kann auch für andere CMS konfiguriert werden, dazu sollten Sie den englischen Artikel zu lesen Customising Jomres to work on other CMSs.

• PHP 5.2.x oder neuer
• MySQL 4.1 oder neuer
• Apache 1.13.19 oder neuer
• ionCube's loaders um Jomres auf den Webserver installieren zu können.
• Eine feste IP. Jomres arbeitet wenn ihr Host einen Proxy nutzt, aber Sie müssen uns kontaktieren um ihre Lizenz zu modifizieren damit unterschiedliche IPs erlaubt sind. Eine shared IP ist prima, solange Sie sich nicht ändert.
• GD muss aktiviet sein.

Jomres arbeitet nicht mit Joomla 1.0.x, da es nicht länger vom Joomla-Projekt-Team unterstützt wird. Wenn Sie Joomla 1.0.x nutzen möchten dann lesen Sie diesen englischen Artikel Customising Jomres to work on other CMSs.

PHP Requirements

Um den vollen Funktionsumfang von Jomres nutzen zu können müssen Sie folgende PHP Features/ Moduleaktiviert haben:

• Socket Funktionen - wird für lizenzierende Produkte/ Kommunikationen mit dem Jomres Lizenz-Server (benötigt). Normal wenn CURL verfügbar ist, ollte dies ausreichen.
• Datei-Stystem-Funktionen - wird zur Sicherung Ihres verschlüsselten Lizenzschlüssel auf der Festplatte und hochladen von Opjekt- und Zimmerbilder (benötigt)
• Kalenderfunktionalität - ( die 'gregoriantojd' Funktion). PHP benötigt zur Erstellung --with-calendar Funktion für den ordnungsgemäßen Ablauf. (benötigt)
• Sie müssen sicherstellen, dass Sie MySQL, XML and Zlib Support in PHP integriert haben. (benötigt)
• Sie müssen sicher stellen, dass sie Safe Mode abgeschaltet haben.

Dies ist eine Liste, die sehr viel Abverlang, doch die meisten qualitativ hochwertigen Provider unterstützen standardmäßig in ihren Hostpaketen diese Funktionen.

Wenn ihr Host eine Firewall verwendet, müss für den Lizenz-Server, damit dieser arbeiten kann, sichergestellt werden, das dieser eine Verbindung nach "*.jomres.net" erstellen kann. Wenn Sie den Webinstaller verwenden muss zusätzlich (nötig) eine Regel zu "*.jomres4.net" (beides auf Port 80) geöffnet werden und CURL aktiviert werden falls dies nicht schon geschehen ist.

Other subjects/ how to do

Jomres does support the use of some WYSWYG editors enabling property managers to "beautify" their property details but their use isn't encouraged.

The problem.

The reason for this that Jomres is designed to allow the site host to offer property listings to many users, and this carries a risk: No user, ever, should be trusted (this is from a php developer's viewpoint, I'm not saying that nobody can be trusted, just that you should never trust data input by a user without validating it).

Inserting HTML code is a risk because it increases the vulnerability to such problems as cross site scripting attacks and whilst we can try to code against it, it's is a never ending race between hackers and developers so it's safest to not include it at all.

Whether by design or by accident, users will always enter data that may compromise the security of a server and it's the developer's task to minimise the risk as much as possible. To do that, we use input filtering to try to sanitise the inputted data as much as possible, but some Jomres site admins demand that certain data such as property details be allowed to be entered while containing HTML code.

The solution.

At the end of the day, you need to consider who's going to be entering data, particularly into the Property Admin -> Edit Property pages. If the only person entering that data is you, and you're unlikely to try to hack your own system, then you can use the HTML editors within Jomres safely. If, however you're opening your site up to other users then you should set the Site Configuration -> Misc -> Allow users to edit using html editors? option to No to ensure that users cannot enter html. You can also improve your security in this regards by ensuring that you're running PHP 5.2 or greater because Jomres then will use the filter_var functionality of PHP to remove invalid code.

A side benefit of this is that users will not be able to insert html code that messes up your lovingly and painstakingly constructed template.

Other subjects/ how to do

As of Jomres v3.2 there is now support for SEF urls in Jomres using sh303sef. This support is limited to Joomla 1.5, there's no point in supporting J1.0.x as it is now in maintenance mode and it's difficult to say how much longer it's going to be supported by the Joomla team.

To enable SEF you can go to the Site Config page in the Jomres administrator area and click on the SEF tab. When you first install you will need to manually move a file from the Jomres main folder (components/com_jomres) to the sh404sef's external extensions folder. The full paths are given in this tab. Once you've done this revisiting this tab will provide you with several configuration options you can use to implement SEF urls in Jomres.

Note that while our support is officially limited to sh404sef and Jomres integration it is understood that the sef plugin in Jomres may also work with artio sef too, but this is outside of the scope of our support so you're advised to experiment youself to get this working.

Other subjects/ how to do

One item that should be born in mind is that Jomres can be very resource hungry. It has been optimised as much as possible to generate as few database queries as possible by preloading a lot of data. This is particularly true in the Property List and Booking Engine functionality however we achieve this by running a handful of queries and storing this information in arrays. This allows us to run a lot of complex code for example in the booking form very very quickly. This means that data that needs to be regularly looped through is instantly available, rather than pulling it from the database but it does mean that Jomres can have very high memory requirements and it is not unusual to get out of memory errors from PHP. The default 8Mb that most PHP builds have available simply isn't enough. Mambo & Joomla themselves both need almost all of this 8Mb simply to run and adding Jomres on the top will definately mean that you will run out of memory. To alleviate this Jomres tries to use an internal PHP function to increase the amount of memory allocated to PHP, however not all servers allow this command to be run and you may need to manually modify php.ini to increase the memory available. Jomres by default tries to set the memory to 128Mb as this is the preferred setting for large systems or systems that make heavy use of the Micromanage tariff mode, but you may well be able to set your memory limit lower to something like 16Mb, 32Mb or 64Mb depending on your requirements.

If you're suffering from out of memory errors, you can try editing your php.ini if you have access to it, and raise the limit a bit like so :

memory_limit 20M

Note that you may need to try different memory limits until the problem disappears.


Alternatively, if your hosting service allows you to, you may also be able to use a ".htaccess" file to raise the limit:

php_value memory_limit 20M

Other subjects/ how to do

This is a series of notes to indicate what each of the files in the gateway plugins do.

Vince's aide memoire to making gateway mini-components for Jomres.

For a long time Jomres was stuck with having a small handful of gateways. Partly because due to time I was unable to create more and partly because each new gateway would require a fresh version of Jomres to release it. V2 has changed that because of it's mini-component handling functionality. Gateways are now handled like mini-components in that they are freely installable (although Jomres has the basic "form" and "paypal" options installed by default).

The components of a payment module in Jomres:

install.jomcompgateway_GATEWAYNAME_.php
j00509_GATEWAYNAME_.class.php
j00510_GATEWAYNAME_.class.php
j00510_GATEWAYNAME_.gif
j00510_GATEWAYNAME_.html
j00600_GATEWAYNAME_.class.php
j00600_GATEWAYNAME_.html
j00605_GATEWAYNAME_.class.php
j00610_GATEWAYNAME_.class.php
j03108_GATEWAYNAME_.class.php
jomcompgateway_GATEWAYNAME_.xml

Obviously _GATEWAYNAME_ is substituted with the name of the gateway in question. Gateways are only triggered at the Confirm Booking stage when the user doing the booking is not an authorised manager.

Brief explanation of each file and what it does:

install.jomcompgateway_GATEWAYNAME_.php

* Called by: Joomla installer class
* Purpose: Removes the automatically created links & admin menu links that are inserted into the fltjos_components table.
* Notes: If these links are allowed to remain, anybody with more than a handful of mini-components would find their "components" backend listing full of mini-component clickable options that are not needed. It also disables you from being able to add links to these components when adding e.g. items to menus for the front end. If you have a specific need for a backend config option then they can be left them in, otherwise it's best to remove them, which is done by this file.

j00509_GATEWAYNAME_.class.php

* Called by: j00501gateways.class.php
* Purpose: To acknowledge existence of the module to the configuration panel "gateways".
* Notes: When the gateways config panel is generated this file is called. It generates the link seen in the config panel that is clicked to enable the gateway module configuration popup.

j00510_GATEWAYNAME_.class.php

* Called by: Independently triggered by clicking on link generated by j00509_GATEWAYNAME_.class.php above
* Purpose: Compiles configuration options that the user can edit.
* Notes: N/A

j00510_GATEWAYNAME_.gif

* Called by: j00509_GATEWAYNAME_.class.php,j00510_GATEWAYNAME_.class.php, j03108_GATEWAYNAME_.class.php (indirectly)
* Purpose: The gateway image
* Notes:N/A

j00510_GATEWAYNAME_.html

* Called by: j00510_GATEWAYNAME_.class.php
* Purpose: patTemplate file used when generating module configuration popup
* Notes: N/A

j00600_GATEWAYNAME_.class.php

* Called by: jomres.php
* Purpose: 00600 module interrupt.
* Notes: function showBookingConfirmation in jomres_bookingroom_functions.php lists active gateway modules. When a gateway is chosen and the customer clicks submit to proceed to payment the module designer is able to program an 'interrupt' that will be triggered before the customer is sent off-site to perform payment. This enables data collection that the system has not collected elsewhere that the module specifically requires. This file is optional, if it doesn't exist then Jomres will skip it and go straight to 00605 eventTrigger.

j00600_GATEWAYNAME_.html

* Called by: j00600_GATEWAYNAME_.class.php
* Purpose: patTemplate file for generating input/output for j00600 class file.
* Notes: N/A

j00605_GATEWAYNAME_.class.php

* Called by: jomres.php
* Purpose: Sends any required postage data to payment gateway, eg paypal. and redirects the user to the payment gateway's interface.
* Notes: Is triggered after 00605, or if 00605 doesn't exist then is called straight away.

j00610_GATEWAYNAME_.class.php


* Called by: jomres.php
* Purpose: Is called by payment gateways confirming receipt of payment, and when customers are redirected back to the jomres site after payment.
* Notes: It is worth noting that the payment data is still only stored in the temporary session data at this point. It is only when the insertInternetBooking function is specifically called, normally by this file but there are other places it can be called, that the booking is transferred from the temporary data to the contracts table. If the process is not completed then the booking is technically lost. Available but liable to be overwritten if the guest should return to the booking form). Also note that in some cases this file may be optional, eg. the cheque (or offline payment) module doesn't use it, the insertInternetBooking function is called by 00605cheque.class.php as there's no extra processing required.

Because the temporary data is stored in session variables it's not unheard of for Paypal's IPN to take so long returning it's information that the session has expired and the data lost, therefore it's advised that you up the Joomla/Mambo session timeout from the pretty short timescale configured by the CMS's to something a little more reasonable. I can't suggest what's reasonable because that's down to you to decide what's best, but I wouldn't be surprised if many people set their timeouts to an hour or more.

j03108_GATEWAYNAME_.class.php

* Called by: function showBookingConfirmation in jomres_bookingroom_functions.php
* Purpose: Reports file path to the calling function.
* Notes: Provides the calling function with the path to the gateway gif.

Other subjects/ how to do

When Jomres calculates prices first it finds the 'base' cost of each room, per night. This is the figure pulled from the tariff rate. Then it will look at all of the rooms & tariffs selected. Say for example two rooms have been selected, one at Tariff 1 (€50pn) and the other using Tariff 2 (€100pn). The base cost of these rooms would be €75pn.
Now it looks to see if any Guest Types exist for the booking. If there are no published Guest Types for the property then by default the Guest Type selection drop down isn't offered or considered in the calculation. If they do exist and if the property is configured to charge on a per person per night basis then further calculations are performed based on the value of each Guest Type. If it is not, then although the guest numbers are included in the booking they are not considered in any way in regards to pricing.
Within the booking engine the Guest Types are part of a larger group called Variances. Variances are elements in the booking who's cost may be calculated as a variance off the base cost of each room. Say for example you have two adults and two children in the booking. Adults are charged at the base cost of the rooms, whereas the children have a 50% discount (see Guest Types for more information). The cost of the adults will be whatever the room costs (€75), whereas the children will be half that each, or €75 for them both. The Total: would be the cumulative value of all four individuals, and the Grand Total: would be the total * number of days staying plus Tax, Single Person Supplement (if applicable) plus any Extras.
Jomres does this all seamlessly, depending on your property settings, meaning beyond creating rooms and tariffs, configuring your property to charge per person per night and creating the relevant Guest Types, you don't need to edit anything else to enable the calculations to take place.

Other subjects/ how to do

This section is a brief discussion regarding the operation of the booking engine.
The booking engine in Jomres is an AJAX driven booking engine designed to make the process of finding available rooms in a property as simple as possible. We use AJAX because it allows the user to experiment with their requirements without having to use the tired old Click -> Submit routine that normally would be used to find and book a room on a truly real time system, or the substantial costs involved with interfacing with a GDS.

The booking engine's main goals are to be as simple as possible to use, removing as many decisions from the hands of the user as possible, guiding them through supplying all the information that they need to enable the system to take a booking from them.

The files

Whilst all operations in Jomres go through the file jomres.php the main files used to generate and perform the booking are done through
jomres.js
dobooking.php
handlereq.php
dobooking_functions.php and
j05000bookingobject.class.php

jomres.js contains all of the booking form Javascript (excluding the actual AJAX Javascript class).
dobooking.php generates the booking form when the user selects the booking link. It builds all of the data required to construct the booking form, initialises the booking data in the Jomres internal sessions and calls the booking form template file.
handlereq.php handles all the AJAX queries from the booking form.
dobooking_functions.php contains the booking object class
j05000bookingobject.class.php is called by dobooking.php and handlereq.php, extends the booking object found in dobooking_functions.php.

All of the booking engine functionality is provided by the jomres_booking class. This class isn't called directly, rather it is called and extended by the booking class which can be found in j05000bookingobject.class.php. The reason we don't call the file directly is fairly straightforward: by creating a new object booking and putting it into a minicomponent of it's own, it's simple enough to override the basic workings of the booking engine without actually editing any of the core Jomres files. To see an example of that install the bookingform_noroomtypeicons Internal Plugin and open j05000bookingobject.class.php in the components/com_jomres/remote_plugins/bookingform_noroomtypeicons directory.
How it works
When a user clicks on an element in the booking form, depending on the element selected the Javascript will trigger an AJAX query which will call the option com_jomres, and the task handlereq. The handlereq task then triggers the inclusion of handlereq.php.
handlereq.php determines the element changed in the booking form and puts this into the variable $field, then handlereq.php will call various class methods depending on which element was changed. When this is done available & selected rooms are returned as output to the booking form and then the show_log Javascript function is triggered. This again calls the handlereq task and any messages required are passed back to the user, as are pricing information and finally, if the booking form is judged to be complete, the Review Booking button is enabled.

The aim of the booking form is to construct a booking in the tmpbookings and tmpguests tables. *Updated: temporary data is now handled by session variables. There are two types of information that are passed to handlereq, Booking Particulars and 'other data'. Booking Particulars are details about the booking that will potentially cause the list of available rooms to change, either by changing guest numbers, smoking options or of course the dates of the booking itself. Other data would be guest names, selected extras etc.
When one of these particulars is changed the system will build the booking object and query all of the rooms on the system using the following methods:

getAllRoomUidsForProperty
findFreeRoomsInDateRange
checkPeopleNumbers
checkSmokingOption
removeFromSelectedRooms
removeRoomuidsAlreadyInThisBooking
getTariffsForRoomUids

The names of the methods are fairly descriptive, but in short all of the room ids are found, and by a gradual process of elimination all rooms who's various status fails to match a given set of criteria are dropped from the $freeRoomsArray variable. This last set of rooms is sent then to the getTariffsForRoomUids method, which will find any tariffs who's criteria also match the particulars of the booking. If a tariff passes then the room id is concatenated to the tariff id with a hat (^) symbol (eg. 3^20). An array of these rooms/tariff ids is built up and eventually this is passed back out of the method. This concatenation allows us to offer a room multiple times for as many tariffs as are valid in that period, so you can for example offer numerous different tariffs over the same time period, offering eg Simple Bed and Breakfast, or Bed, Breakfast and Evening meal tariffs for the same room over the same time period.
This array of room ids and tariff ids is then passed to the generateRoomsList method which actually creates the lists of available and selected rooms for display in the booking form.

Once the rooms list has been passed back show_log is called, and depending on what was previously changed it may or may not recalculate the price list. If Yes, then the generateBilling method is called, this will trigger the pricing calculations to be performed, then finally various data is returned  to the jomres.js script and evaluated using mainly the getElementById Javascript function to set various divs in the booking form to the updated fields.

Other subjects/ how to do

This section describes minicomponents, what they do and how they work. See also Customising for more information on the subject.

What are mini-components and why are they needed?

Mini-components are actually separate files that Jomres can call that either replace or add to existing Jomres functionality. They are very useful if you have modified existing Jomres code to suit your own requirements. If you simply edit the standard Jomres code then when you upgrade you will need to make sure that you have backed up your changes otherwise you will lose them. They also make it very easy for me to provide extra code to enhance the current Jomres functionality without bloating the standard Jomres install.

Mini-components are structured in such a way that they can be installed using the standard Mambo installer, and uninstalled the same way.
Whilst it's still possible to install minicomponents this way, the majority of minicomponents have been converted to remote plugins and are installed using the Plugin Manager.

How do they work?
Without going into too much detail, Jomres has many core mini-components that it knows are kept in the /components/com_jomres/core-minicomponents folder. When Jomres starts it will scan this folder for these files. Next, it will look in the /components/com_jomres/remote_plugins folder for more plugins. After that it will look in the CMS components table for any other components that start jomcompXXXX. If it finds any it will look in these other folders for any files that start jNNNNN and make a note of them. If a file exists with the same name as a Jomres core mini-component, (e.g. j00013dashboard) then this file and it's contained functionality will be used instead of the core Jomres file.

So, first core-minicomponents, then remote_plugins, then finally other directories in the components/ directory.


Give me an example of why I'd use them
In the days before mini-components, if you wanted to change how Jomres worked, you had to modify the core Jomres code and make sure you had a backup of your changes. When it came to upgrading you had to install the upgrade and look at your old files and make again the changes you'd made before. This was very frustrating and time consuming. Using mini-components this is no longer a problem.

So, how do I use them?
We will use the dashboard as an example.
Let's say that I want to change the dashboard so that instead of showing the standard dashboard view, it doesn't show anything. First, I'd download j00013dashboard.class.php and save it locally. I'd edit it to use it as a base for building my own mini-component.
Now I need to decide on a name for this mini-component. There are no strict rules on what it is called, so you can name it pretty much what you like, however there are certain places in the naming of the mini-component installer files where they all need to be the same. I'll go through each of these files in turn:
jomcompXXXX.xml
When Mambo installs a component it uses the name of the xml file to decide where to put the files, therefore inside the xml file where it says <name>jomcompXXXX</name> you should replace the XXXX with what you're calling the file, e.g. 'myminicomp'. Note, that you must keep the 'jomcomp' part of the name intact, as this is what Jomres looks for when searching for mini-components in the Mambo components table.
Where is says <description>Base mini-component installation files </description> you should enter a description of what your mini-component does. Try not to use any special characters or html in here otherwise the installer may fail (encase them in CDATA if you need to).
Where it says <installfile>install.jomcompXXXX.php</installfile> and <filename>install.jomcompXXXX.php</filename> you should change the XXXX again to the name of your mini-comp, e.g. 'myminicomp'.
<menu>jomcompXXXX</menu> is required by the installer but not actually used. Again, change XXXX
Finally, but just as important as the other xml tags is this one: <filename>j00013XXXX.class.php</filename>. This is the file that will replace the standard Jomres functionality.

install.jomcompXXXX.php

This file should have the same name as that in the xml file, so if you've changed  <filename>install.jomcompXXXX.php</filename> to  <filename>install.jomcompmyminicomp.php</filename> then your install.jomcompXXXX.php should now be named install.jomcompmyminicomp.php

Inside this file there's a line: $componentname="jomcompXXXX"; Change it so that the $componentname reflects the name of your new mini-component ($componentname="jomcompmyminicomp";)

All this file does is remove the Mambo backend and front-end menu options, we don't want to add this mini-component to Mambo or use Mambo to configure it. If this mini-comp offers configuration it'll be done through Jomres.


j00013XXXX.class.php

This is the actual file that will replace/enhance the core functionality. If we are replacing the original dashboard then we will call it j00013dashboard, if we are adding to the dashboard functionality without replacing the current code then we need to come up with a slightly new name. For example we might want to display a welcome message for the admin underneath, in which case we could call it j00013welcomemessage. What's important here is that the trigger point (00013) must refer to one already existing in Jomres. If the trigger point doesn't exist then this file will not be used.

In this instance we want to replace the core mini-comp j00013dashboard.class.php with one of our own, so the first thing to do is copy j00013dashboard.class.php and drop it into our new mini-component's folder. Once we've done that we can make the changes we need to make to it to do what we want.

For each file you want to replace (in theory, you could replace nearly all of the core mini-components in this way) you need a tag in the xml file and the corresponding file needs to exist in the folder before you zip it up.

If you've done everything correctly you should now be able to zip this entire folder up (call it anything, the name of the zip doesn't matter) and use the Mambo installer to install the files.

There you go, your first mini-component.

Notes:
If you want to include your own template files instead of using the standard Jomres ones you can do that, but you need to tell patTemplate that you're looking in this folder instead of the Jomres folders. This is done by using the $ePointFilepath; variable. First make it global, then when you set the root of the template do it like this: $tmpl->setRoot( $ePointFilepath); This tells Jomres that instead of looking in the standard template folders, look here instead. Don't forget to add the template to the xml file so that that's also uploaded to your mini-component's folder.

Don't be shy about looking at existing minicomponents. This is a very short tutorial on a very powerful subject within Jomres, there's a lot more to learn.

Other subjects/ how to do

In Jomres it's trivial to edit a language file, you can exchange the word Room for Yacht easily, it's slightly more difficult (but not hard anyway) to use the context sensitive editing mode to make text specific to a property. Using this you can have say Hotels and Camp sites on the same server but it does require that the property manager (probably you) set up completely separate text for the camp site to override the standard Jomres hotel text.

A new way around this has been devised. As you're probably aware, you can have property types in Jomres. You may also be aware that the description field wasn't being used anywhere by Jomres so a new use has been made of that field in the database.

As of 2.6.0.1 you can create a sub folder in the /components/com_jomres/languages directory (or you can look at the ones already created for you if you've installed 2.6.0.1 or later) and call it something eg. 'dvdrentals'. Put a copy of english.php (or any language you like so long as your CMS is configured to use that language) in that folder and change words from eg Rooms to DVDs, Room Types to Genres etc. Finally, in the administrator backend Global Property Types create a property type with the name 'DVD Rentals' and the description 'dvdrentals' and Jomres will find that new language file and use it instead of the standard Hotel based one.

What Jomres does when it starts is try to find the property uid. If it can it'll then find the property type and look to see if a file by the name of /administrator/components/com_jomres/languages/*propertytypedescription*/*currentlanguage*.php exists. If it does it'll use that. Just remember, that the name of the folder that the new language file is in and the description in the Property Type Description needs to be the same, and that there should be no spaces between words. Therefore 'dvd rentals' would be wrong, but 'dvdrentals' right.

To get you started new installs from 2.6.0.1 come included with some slightly modified versions of the language files for Yacht Brokerages, Camp Sites and Vehicle Rentals, and Property Types to match. Just remember that if you're not looking at a specific property then the default language file will be used, and if you've not edited that, then it's language context will still be Hotels.