Paula
Forum Replies Created
-
Hi guys
Thanks for the answers, glad I could be of any help. I was already looking at this piece of code, so it’s good to see a proper way of handling this script. For the inline css there has to come a way to properly enqueue/dequeue it, I think. For now I’ll stick to the blunt way of doing a string manipulation.
Cheers
Paula Dieterman
And just to be clear, I meant the https://wpf-lite.instawp.xyz/ test site. Every page has the script (Frontend.php) and inline styles (coming from CssVars.php) added to the head section. The script is scouring the page looking for a form. For now I’ll manage with preg_replacing the head section, but this really shouldn’t be anywhere but on a page that actually contains a (wp)form. And regarding the inline css: if you have opted to have no styling at all this just shouldn’t be anywhere, period.
Cheers
Paula
- This reply was modified 2 years ago by Paula.
Hi
You should have a closer look at your test site, because I can see the exact same behaviour over there. In your inspector select the ‘<head>’ section and you’ll the css properties declared, as well as the inline script, which is generated in the Frontend.php file
- This reply was modified 2 years ago by Paula.
I noticed this too today (don’t know if this is a recent issue, only been using wpforms for a few days). Some inline script and a bunch of css variables are displayed globally on every page. Styling is set to none, loading assets globally to off.
You’re welcome! Thanks for the quick response, it seems to be ok now.
Paula
Forum: Plugins
In reply to: [SlimStat Analytics] Slimstat is slow on a brand new websiteIt’s mentioned before in another thread but the plugin also takes a hit on admin-ajax.php, By design of course, but the difference between using slimstat and not using it is ~ 2 seconds in page loading time in my case, even before the new fingerprinting algorithm functionality was deployed. I guess every analytics tool is a burden on page loading performance, and maybe what you see here is the difference between *measured* page speed and *perceived* page speed. I’m quite picky when it comes to page speed performance and I don’t think it’s worth my wile seeing all of my hours of tweaking getting undone by using a statistics plugin.
Best wishes
PaulaForum: Plugins
In reply to: [SlimStat Analytics] Another javascript errorHi Jason
Thanks for the update. I replaced the latest – official – version with this one on my dev site and the error is gone now, great! I think I’ll wait for the next official release to update the live version.Thanks again
Paula
Forum: Plugins
In reply to: [SlimStat Analytics] Javascript error (TypeError)Hi Jason
I’ve updated to 4.8.7.2 and can confirm that the error is gone. Thanks!All the best,
PaulaForum: Plugins
In reply to: [SlimStat Analytics] Javascript error (TypeError)Thanks for the quick response. Still puzzling though that only Chrome would produce this error.
Thanks again
PThanks for the reply, and sorry for the bump, my bad…
I don’t think saving the image twice is the best solution. Aside from added disk space consumption, it only adds more to the confusion. Generally I don’t like files with a double extension when there is no real need for it, but I can see the logic here. Maybe saving the name.jpg as name.webp, unless there is a name.png already present and then saving name.jpg as name.jpg.webp (or name.png as name.png.webp and name.jpg as name.webp)? But this implies kind of a reversal in behaviour which will cause other problems, I guess. Regarding the symlinks, I would prefer server side directives. For me personally, I don’t mind renaming the files, it’s a trivial process.
Thanks
PThanks for your reply, I now see the logic of this behaviour. But… the reason I noticed it is because of the CacheEnabler plugin still referencing to the jpg versions in the webp cache files and not the webp counterparts, so name.jpg instead of name.webp. The creation of symlinks would be a workaround only if they are actually being created on my server, but they aren’t. So name.webp isn’t served, only name.jpg.webp.
My workaround is renaming the *.jpg.webp filesThanks
PHi
I encountered the same problem with images I uploaded recently. There were three images which were optimised, but no webp version was created. First I thought this was because I added the images with the WordPress iOS appeared. I added another one – now through the web interface, that triggered the three previous images being optimised again, but now with a webp version added. The newest image was optimised, but without a webp version. I uploaded it again, still no web version. This way I’m burning my credits at double rate. One for optimisation without webp, andcone for yet another optimisation with webp. This is annoying to say the least. I hope you can figure out what’s happening here.Thanks
Paula