lqpman

Yes, it’s a shame indeed. Changing hosts for my site is not an option either – my site is currently hosted at my University’s server which hosts the professors’ academic webpages, and I have almost ten years of content there.

I simply cannot afford to pay on my own (in fact, I don’t even know if I’m allowed) to outsource the hosting to another, paid WordPress server (so I’m able to use plugins) just to get a newer PHP version, not to mention the work and time needed (which I don’t have) to migrate even just the parts of my site which are essential to my current teaching.

Thanks again!

@benbodhi Thanks for your reply. Unfortunately, my current version of the SVG Support plugin (2.3.15) is the latest one compatible with my version of PHP (5.2.10 – ikr?), so updating it is not an option until the server admins are able to update PHP as well. There’s nothing I can do about that at the moment – I even tried to ignore the PHP version guidelines and update the SVG Support plugin anyway, but the new version chokes with the syntax and parsing changes in PHP from version 5.6 onwards as compared to 5.2. Moreover, the only option currently active for the SVG Support plugin is inline rendering, since, as I said above, I cannot do without it if I want to use SVG.

I’ve also noticed another problem: I’m starting to use slightly more complicated LaTeX code in another page of my site. If I enforce formula image file format to be SVG, several (but not all) the formulas there get scrambled – some don’t render at all, others become filled with gibberish or are strangely cropped, and some others are rendered normally. I guess that with simple enough formulas (as in the page linked in the OP) the problem doesn’t show up in all its g(l)ory. The only way to get all formulas correctly rendered is to use PNG instead, with the associated scaling penalty which is inherent of bitmaps and the longer loading times in the first access (albeit only then, thanks to local caching).

Anyhow, I think I’ve reached the limit of what I can do about the problem at the moment, and my lectures resume tomorrow. For that I need my site functional, so I think I’ll leave QuickLaTeX set to render formula images in PNG format for the time being and visit this thread from time to time to check whether some answer has been found or not. Thanks to all for all the help, though!

• This reply was modified 4 years, 7 months ago by lqpman.
• This reply was modified 4 years, 7 months ago by lqpman.

I’ve cleared both the WP Super Cache and QuickLaTeX caches, and deactivated all my WordPress plugins except SVG Support, QuickLaTeX and WP Super Cache. The problem remains – if I leave the saving format setting for QuickLaTeX formula image files as “Auto” no formulas are rendered. Setting this back to either “PNG” or “SVG” brings back the formulas (with the above P.S. proviso that the scaling of the formulas differ from each other in those cases).

Finally, if I deactivate the SVG Support plugin as well, the formulas are no longer rendered with the “Auto” and even with the “SVG” option, so the SVG Support plugin (with inline SVG rendering active, since these are all inline formulas) or another WordPress plugin with the same functionality is absolutely needed. Only the “PNG” option works in this case. I took care of deleting all caches before doing this as well.

That still left the possibility that the problem is caused by my theme (Fashionistas). I’ve tried to switch the theme to something more canonical like Twenty Nineteen or Twenty Seventeen (considering my WordPress version, it’s a good idea to be conservative) and clear all caches once again, but the problem remains the same.

• This reply was modified 4 years, 7 months ago by lqpman.
• This reply was modified 4 years, 7 months ago by lqpman.

Hmm, that’s odd. If I force the locally cached formula images to be saved in .png format, the page indeed loads normally.

According to the official plugin description, the SVG Support plugin “uploads SVG files to the Media Library and render SVG files inline for direct styling/animation of an SVG’s internal elements using CSS/JS.” More details can be found at the WordPress plugin’s page – or, even better, from the plugin creator @benbodhi’s comment above (kudos!). I was using it (version 2.3.15) for ensuring proper rendering of SVG images in this and other pages in my site as it’s done for other (bitmap) image formats – or at least I thought so.

It turned out that the only two images (in another page) of my site which I believed to be in .svg format were in fact in .png format. I tried to load a proper .svg image for testing purposes in that page, with no success. Deactivating the SVG support plugin changed nothing – no .svg images were rendered at all. After I reactivated the SVG support plugin and played with its advanced settings, forcing inline SVG brought the rendering of .svg images back, as suggested in the SVG Support plugin’s FAQ. However, this only works if I deliberately set QuickLaTeX to save the formula images in .svg format. If I leave it in “Auto”, the formula images no longer render again – probably some JS/CSS script is getting messed up due to the interaction between the QuickLaTeX and the SVG Support plugins in this case.

I could of course simply leave it configured for saving formula images in .svg format, but that may hinder site compatibility with older browsers; leaving in .png format instead, on its turn, brings up the typical scaling problems bitmap images have. I reckon that the “auto” format allows the browser to choose the best option for itself.

In view of that, since my site (with the current versions of WordPress and PHP) cannot render SVG images without some sort of plugin, is there some other WordPress plugin for rendering SVG images which you recommend for use with QuickLaTeX (with a version working with my versions of WP and PHP)?

P.S.: curiously, the size of the inline formulas is different, depending on whether you render them in .png or .svg format – the latter keeps the inline formulas at rigorously the same size as the text font, whereas the former gets the inline formulas slightly larger.

• This reply was modified 4 years, 7 months ago by lqpman.
• This reply was modified 4 years, 7 months ago by lqpman.
• This reply was modified 4 years, 7 months ago by lqpman.

In due time, @advanpix: I’ve used Firefox’s HTML inspector to check the HTML code of the page and see whether your hypothesis about the formula images’ URL’s being scrambled by something is true. In fact , it’s not: the URL’s not only match precisely the name and location of the formula image files on the ql-cache subfolder, but also if I copy the URL’s to a separate tab and load them alone, the browser is able to load the images normally. Only when the formula images’ URL’s are embedded into the page code as they are does the loading fail.

This also reinforces my impression that the problem is not permission-related.

• This reply was modified 4 years, 7 months ago by lqpman.

Thanks for the reply. However, I don’t have the Jetpack plugin installed, so the cause must be something else. In fact, should I have the Jetpack plugin installed in my case? I’ve got word that only high-traffic sites need to bother with it. If so, I need to figure out which version of Jetpack is compatible with my versions of WordPress (5.1.4) and PHP (5.2.10), particularly the latter since, as I said above, my server’s admins won’t be able to update it in the near future – according to Jetpack’s changelog, the latest such version seems to be 7.3.2.

Moreover, I have (.svg, .png and .jpg) images in this and other pages in my site, and they are loading normally with QuickLaTeX’s local cache enabled. Only the QuickLaTeX formula images are being affected.

By the way, I don’t know if it’s related, but the CDN support is disabled for my site.

• This reply was modified 4 years, 7 months ago by lqpman. Reason: Added explanation
• This reply was modified 4 years, 7 months ago by lqpman.
• This reply was modified 4 years, 7 months ago by lqpman.
• This reply was modified 4 years, 7 months ago by lqpman.

Hi there,

Same problem as above: after following all steps for installing WordPress, get the same

“Your PHP installation appears to be missing the MySQL extension which is required by WordPress”

message when trying to load wp-admin/install.php to complete the WordPress installation. I’ve checked _all_ possibilities discussed above: the php.ini file of _both_ my php4 and php5 installations have uncommented “extension=mysql.so” lines (also “extension=mysqli.so” for php5), these modules _are_ present, and my Apache-PHP-MySQL setup _does_ seem to work, for I have phpmyadmin installed and it _does_ work as it should – all MySQL management can be done by PHP from my Firefox web browser. The WordPress files are the _only_ ones which complain as if there was something missing.

My machine runs Ubuntu Linux 6.06 (“Dapper Drake”), and all versions of the needed packages seem to be up to date.