Could you walk me though the steps I could follow to reproduce the problem? Here is what I’ve tried so far:
On a site where Photon was active, I activated the WP-QuickLaTeX plugin, and then went to QuickLaTeX > System. There, I changed the image format svg. I saved my changes, copied the sample text available in QuickLaTeX > Getting started, and published a new post with that text.
However, the images are displayed properly and Photon didn’t add any resize parameter to the images:
http://i.wpne.ws/f9aS
Is there something I’m missing here?
Thanks!
Coming back to this, I just noticed this thread. There, you mentioned that another Jetpack module, Markdown, caused issues with the formulae.
It’d be great if we could work together to make sure that doesn’t happen. Is there a specific pattern we could look for when processing text, something that the Markdown module shouldn’t process? I see you use \[..\] in your plugin, and I wonder if that’s what gets stripped out by the Markdown module?
– Yes, as for Markdown, it strips off all the “\” in text.
In LaTeX language this is probably the most important symbol – every command should start from “\”.
– As for Photon, QuickLaTeX > System > Image format: Auto.
In this mode QuickLaTeX uses PNG by default (on page load), but then replaces image URLs to SVG if browser supports it (by JavaScript).
In this way we have graceful fall-back in case of older browsers.
I have just realized that probably I should strip off the “resize” using JavaScript after switching to SVG in browser.
– Yes, as for Markdown, it strips off all the “\” in text.
In LaTeX language this is probably the most important symbol – every command should start from “\”.
Indeed. We actually check for LaTeX code before to process content with Markdown. To do so, we check for this LaTeX code pattern: $latex some-latex-text $
We also check for shortcodes thanks to core’s get_shortcode_regexfunction (reference), and thus preserve WP shortcodes from being formatted by Markdown in any way.
Unfortunately, the pattern you use in your plugin (\[..\]) is not covered by our plugin.
I think we could work around that problem by adding a new filter to Jetpack, that would allow you to define your own custom pattern. Check this Pull Request I just created for an example:
https://github.com/Automattic/jetpack/pull/3415
If that seems to work, we’ll include that filter in the next Jetpack release.
then replaces image URLs to SVG if browser supports it (by JavaScript).
Thanks for the extra details.
That’s most likely the source of the problem here. Photon processes the image because it’s a PNG file, before it gets replaced by your JavaScript.
I can think of 2 ways to work around that problem:
- You could, as you suggested, get rid of the Photon parameters via JavaScript. While that will work, it’s worth noting that
resize might not be the only parameter added to the image. There are quite a few other parameters available in the API, that will be added by Jetpack itself in some cases (Retina devices, specific image size, …), or by other plugins and themes leveraging the Photon API and adding their own parameters (here is an example). It could be tricky to support all parameters, and stay up to date.
- Another work-around would be to make sure images generated by your plugin never get processed by Photon in the first place. Here is how you could do that.
Let me know if it helps.
We actually check for LaTeX code before to process content with Markdown. To do so, we check for this LaTeX code pattern: $latex some-latex-text $
We also check for shortcodes thanks to core’s get_shortcode_regexfunction
Using shortcodes to include LaTeX is very inconvenient. Just imagine how would you publish excerpt from your scientific paper on your blog. All the hundreds of LaTeX pieces of code would require manual wrapping with $latex …$. Nightmare.
There are a lot of possible LaTeX patterns (\[..\] is one of many).
This is one of the reasons QuickLaTeX supports native LaTeX syntax without any shortcodes (shortcodes can be used too, of course). This allows copy-paste exchange with offline LaTeX papers.
The second way would require to detect the presence of JetPack/Photon.
Just stripping off everything after file extension in URL looks universal enough (?)
There are a lot of possible LaTeX patterns (\[..\] is one of many).
Do you think we should expand our current LaTeX detection in Jetpack to include more patterns by default, even before the filter I mentioned earlier is run?
The second way would require to detect the presence of JetPack/Photon.
You could check if the class exists. That should be enough.
Just stripping off everything after file extension in URL looks universal enough (?)
Yeah, that could work indeed, although I can’t speak for other plugins that may added parameters to image URLs.
I am not sure what to do in case of Markdown – LaTeX has a lot of patterns.
We can try using the new filter as you proposed in pull request.
Every pattern would need distinct filter?
As for Photon – it adds the suffixes to URLs after QuickLaTeX already processed the page. Disabling Photon before (and turning it on after) QuickLaTeX processing, as suggested in post – won’t help then.
Or this can be changed by adjusting filter priority?
We can try using the new filter as you proposed in pull request.
Every pattern would need distinct filter?
I’ve modified the patch a bit to allow you to pass an array of patterns. It should make things easier.
it adds the suffixes to URLs after QuickLaTeX already processed the page.
I guess that depends at what point of the page QuickLaTeX generates the images to be used.
In any case, removing the parameters via JavaScript should indeed work!
