First things first, a couple of people may be aware of a reported CSRF bug in Jomres. I tested the PoC as described as soon as I became aware of the report and I'm delighted to say that the report is false. Nevertheless I made the JED and VEL aware of the report and my findings.
The GDPR update went very well and I'm pleased with the result. I'm content that the users who have updated their Jomres installations are, at least as far as Jomres is concerned, compliant. Joomla as yet have not released their privacy update version which will include new functionality specific to the subject, I will adjust Jomres accordingly when that's required.
New functionality has been added to the Beds24 integration plugin which allows site administrators to, via the Site Configuration > Integrations tab, set a master API key that all properties in the site will use.
IF YOU ALREADY HAVE AN INSTALLATION OF JOMRES WITH PROPERTIES LINKED TO BEDS24 READ THE ENTIRE DESCRIPTION HERE. By default Jomres is designed to be a multi-vendor booking platform. Managers who have their own beds24 accounts can import their properties to and from beds24 securely. This setting allows you to override that functionality by having a single api key for all properties. This means that you only need one account with Beds24 however it also means that all charges will be accrued by that one account. Any manager with access to a property will be able to send updates to the property on the beds24 servers. Leave blank to ignore this setting and force property managers to use their own Beds24 accounts. The API key can take any form you want, so long as the key here matches the one in the API Key 1 field in your Beds24 account.
IF YOU ALREADY HAVE AN INSTALLATION OF JOMRES WITH PROPERTIES LINKED TO BEDS24 : You can switch to using this feature, however it would require that you first truncate (empty) these tables, delete the existing properties that are already in Jomres, and that you then re-import the properties from Beds24 into Jomres. XXXXX_jomres_beds24_contract_booking_number_xref , XXXXX_jomres_beds24_property_uid_xref , XXXXX_jomres_beds24_rest_api_key_xref , XXXXX_jomres_beds24_room_type_xref.
The next version of Jomres will probably be released early next week. The new version includes a couple of features which I think will be of interest to our users.
The first new feature is the Frontend Room Type editing feature.
This has been requested a lot over the last few years and I'm pleased to announce that this feature will be in the next version.
Quite a few times users have wanted managers to be able to create room types for their own properties. I had resisted this for some time because humans being humans you would inevitably end up with a combination of "Double bedroom", "Dbl bedroom", "Double br" type room types, all pointing at more or less similar room types in the search fields. As a result two settings in Site Configuration > Misc tab will affect this feature. The first is the ability to switch the feature on and off. The purpose of that is obvious. The second is a switch that will allow site admins to prevent these custom room types from appearing in search option fields. This then places the onus of managing the feature on the site administrator. The only feature that's missing from here, and I'm not sure if it's needed but will add if required is the ability for site administrators to see these property types in the administrator area. I'll wait for user feedback to see if it's needed.
A new class has been added to Jomres. In and of itself it doesn't do much, however it's existance means that it's easy for plugins to hook into the system to provide machine translations and a new plugin will be available in the Jomres plugin manager called DeepL.
The plugin works like this : every time Jomres wants to show some text in a template, the string required is parsed throught the jr_gettext function and is in turn passed through the jomres_language class. Every one of these strings is identified by a dynamic definition. Internally Jomres will check the custom text database to see if a custom string exists for this definition. If the custom string does not exist then Jomres will pass the original string (e.g. "Double room") off to the DeepL translator service. Sadly it's not free, but it is very reasonably priced for the benefit that it brings, as you will see.
Once DeepL returns the translation, we will save the translation to the custom text table. This means that you will
- Be able to refine any translations that you think need to be improved upon via the Label Translation tool in the Administrator > Jomres > Translations > Label Translations page and
- Your server will not constantly be calling the DeepL service, building up charges.
As I mentioned on Facebook, this first iteration of the plugin has worked really well. Translating a basic quickstart installation of Jomres labels automatically from English to Spanish was a little slow, but that was to be expected. A few page reloads ensured that all of the labels were translated. Approximately 1100 new rows were added to the custom text table automatically, and that consumed a little over 20k characters. Given that a 20€ subscription includes 1,000,000 characters, there's plenty of surplus characters even for larger sites. Remember that each string's translation is only done once, when it first becomes visible in a given language. This includes things like property descriptions.
The feature isn't perfect yet, and I will mark it as experimental for now but I'm sure you appreciate that this is a fantastic tool for getting a site up and running quickly. It's a massive time saver. You now don't need to spend time translating different strings, it's all done for you and all you need to do is fine-tune some of the translations.
DeepL currently supports English, German, French, Spanish, Italian, Dutch and Polish.
Once the new version of Jomres has been released I will release the DeepL plugin for our users to help with testing.
I hope you've enjoyed this status update and that you have a great weekend.
- Created on .