Forum Replies Created

Viewing 12 replies - 1 through 12 (of 12 total)
  • Hello @safetyllama,

    Thank you for pointing this out. We are aware of this issue and we have an issue open on our GitHub page:

    This is happening because this plugin was designed to run on production servers using Linux, mainly Ubuntu servers.

    If you are on a Linux environment, please make sure that /tmp is writable and it’s not locked for the www user.

    We’ll consider implementing a fix for this in the near future so you can use it in a local environment or any other environment as well.

    Best regards,
    ~Presslabs Team


    We have implemented this in production and it seems to be working.

    I am using your new function above and the ‘tiny_image_after_compression’ hook to refresh the CDN cache for that image using its ID.

    I’ll let you know if I encounter any issues, otherwise please merge this new function in production as we’ll be also pushing our cache refresh code in production on our next deployment.

    Best regards,

    Hello Arun,

    Thank you for your help.

    Indeed there are not many users which need support for custom paths, and for these that need I believe a simple filter should be sufficient. Adding a form and extra settings in DB might be overkill. Not sure though. If there are sufficient users requesting this it might be worth it.

    The hosting company is Presslabs

    Best regards,

    Hello again,

    I believe I’ve managed to fix this, yet I would like your approval to make sure that this is the right way to do it. Also if you can implement these filters in the production plugin so that we won’t lose these after an update would be awesome.

    Here is the PR in case you want to merge it in production. We would hate to see the fix break on an update 🙁

    In the functions.php file inside the theme we have added this for it to work:

    add_filter('superpwa_manifest_abs', 'fix_abs_paths_for_superpwa');
    add_filter('superpwa_sw_abs', 'fix_abs_paths_for_superpwa');
    function fix_abs_paths_for_superpwa()
    	return trailingslashit(get_home_path() . 'wp-content/root');

    After the fix, I can see Service worker generated successfully. inside the Settings page of the plugin.

    Best regards,

    For us, a filter for the ‘abs’ $arg would be sufficient, yet I belive you should also add a filter for the ‘src’ $arg as well.

    Hello, @simonstone,

    I just want to come back on this as we are actively using this plugin and need a fix.

    To add on to what Simon said earlier, the problem came after the last update.

    Here are the hosting specifications maybe it can help in debugging:
    WP 4.9.6 running on NGINX with PHP 7.1 and the DB is Percona 5.6.

    If you can help me with some insights from where this issue can occur since the last update I am able to have a look and try to debug further.

    Best regards,

    Hello Simon,

    Sorry for my late reply.

    All plugins on the site are disabled, the only one I was running was this one, as you can also see in the video provided.

    Also, to be noted that these logs appear only when I click an image (when the upload happens I assume).

    The issues are the following: 1) the upload process is buggy and not all thumbnails are being generated properly. 2) the image is not getting added to the post after selecting it as you can see from the video, you need to go and re-select it manually from the gallery.

    Awaiting your reply with high interest.

    Best regards,

    Just wanted to check up on this, are there any updates?

    Do you have at least any clues?

    I am talking after the static files, which are linked to the location specified in the field which defaults to /s I guess.
    Here is an example:

    NOTE: My hosting is automatically rewriting all my URLs for static files to CDN. Still, I can’t find the actual files on disk.

    My hosting has the “root” folder inside wp-content/root/ which is sym-linked inside the docker container to the actual site root and all WP default files and folders like wp-admin and wp-includes are read-only. Maybe this will help you guys debug the issue further and make it compatible with all hosting environments especially the modern use of distributed systems like kubernetes and docker.

    BTW: We are going to use this plugin on multiple high-traffic sites with millions of page views monthly so we need it to perform very well and thus far it’s working wonderful in our tests. Keep up the good work guys! You did it very well and easy to use.

    Thank you. I have found that option right after writing this support message.

    Still, I am facing another issue: If I’m using the first option for the parser, Standard HTML parser it does not parse anything,- or not always I can’t tell. Sometimes it does minify the HTML sometimes it doesn’t; it depends on the options I chose. But the JS/CSS merging doesn’t work at all only in Fast Simple HTML parser.

    Anyway, using Fast simple HTML parser works perfectly. With a single exception, the merged files for JS/CSS are 404-ing. And I can’t seem to find where these files are generated on disk for me to create a nginx redirect to them.

    Where are the merge files saved? Can you guys save them in a folder inside the uploads folder and link them from there?

    Thank you for the quick reply and for the helpful response.

    I was about to feel bad after reading your last comment for just purchasing this plugin before I have compared the results in the SEO Research Tool with the results from which are similar. Even more, Squirrly gave me better suggestions and keywords ideas to rank for + the assistant is amazing and give you good suggestions especially for beginners on what to do for the post to rank.

    Now I am confident the plugin is good, especially that it’s faster and much better optimized then yaost and does not put unnecessary load on my backend.

Viewing 12 replies - 1 through 12 (of 12 total)