Today I've been working on modifying Jomres behaviour in WordPress, specifically with respect to how it behaves when the theme doesn't offer Bootstrap. All of the work I've been doing recently is for Bootstrap 5 based sites, so changing the CDN loading from BS3 to BS5 allows more users to use the newer plugins.

Happily the work went great. Where previously Jomres would load CDN based copies of Bootstrap 3, it now loads Bootstrap 5 & Fontawesome. I also needed to look at the js and css loading functionality because while it worked fine in Twenty Twenty theme, it wouldn't work in Twenty Twenty Two. Given that all of the development work I'm doing now is for Bootstrap 5 based sites, I had to resolve these two issues if users want to use all available plugins.

I'll be honest, I'm pretty chuffed with how it looks, even on basic themes like Twenty Twenty Two.

However!

 (There's always a however, otherwise what's the point of a blog post?)

I came across an annoying problem. Firefox's browser console alerted me to a problem by reporting

Uncaught SyntaxError: '#' not followed by identifier

and when I looked more closely at the page source I saw that javascript from the dashboard, instead of being

if (startDate == endDate && whole_day_bookings == '0')

it was in fact

if (startDate == endDate && whole_day_bookings == '0')

It's no surprise that Firefox was throwing a wobbly. I learned that the problem was with wptexturizer which treats a rendered Jomres page as untrustworthy so it tries to santitise post data before it's presented to the user.

Now, I'm a great believer in security. Jomres has it's own input filtering code, and has for years. It's been a portal system for 17 years and in all that time I've treated user entered data as insecure so I've always striven to ensure that any data is sanitised long before it ever hits the database. I can kinda see where the WordPress developers are coming from with this solution, I've done similar things myself.

After a bit of Googling, I came across this stackoverflow post. The user was having similar problems to me, so I gave the solution a shot. I had to replace

$tags = array(' <!-- noformat on -->', ' <!-- noformat off -->');

with

$tags = array('/* noformat on */', '/* noformat off */');

because the html comments code broke the javascript, but it worked. Sorta.

I then discovered that wptexturizer was adding br and p tags to the rendered html content, causing yet more javascript errors. It also explained why I had a heck of a lot more whitespace in rendered Jomres templates than had any right to be there.

I tried everything, but nothing I did would work, including adding no_texturize_tags filters, probably because of how Jomres works. All the googling I've done throws up scores of results about disabling the function. It seems I'm not the only person who's been frustrated by the problem.

The only solution that actually worked was adding this line to the Jomres WP CMS bridging code. On installation and update of Jomres the bridging code is copied from that directory into the /wp-content/plugins/jomres directory.

add_filter( 'run_wptexturize', '__return_false' , PHP_INT_MAX );

What this does is it completely disables the wptexturizer function on any page that the Jomres plugin is run on.

Is it dangerous to remove this function? Maybe, in theory.

What wptexturizer is doing, as far as I can tell, is preventing javascript that a malicious user might have saved, typically in a blog post, from running on the post's display. So, in theory if you have guest posters who have figured out ways of evading WordPress's input filtering, then it's possible that by disabling this WordPress function I've opened up a crack in WordPress's armour.

The truth is, I think that function is probably overkill. As I already said, Jomres already sanitises data saved by property managers, even if the administrator allows use of html editors, and WP santises using it's own input filtering on posts.

On balance I'm satisfied that it makes sense to remove this function when rendering a Jomres page. If you're an admin and you allow guest posts by people you don't trust then one precaution that you could take is to not show guest posts on the same page that Jomres is run on. On any non-Jomres page, wptexturize is still going to be run, so show those posts there instead.

Honestly, I think that this is overkill too.

Wrapping up

I've googled and googled and I can't find any rationale that stresses that it's best to leave the wptexturizer function enabled. I've found absolutely scores by designers complaining about what it does, but none that say that it should be retained. If you know different, please do drop me a line.

 

WordPress, Input Filtering