Support » Plugin: Add Watermarks » Site slows down dramatically even after first time

  • Resolved miyurusagarage

    (@miyurusagarage)


    Hi this plugin is perfect for my site, however, it slows down the loading time, even after the first load. Could this be that somehow it does not cache the images properly or .htaccess is not working properly for me? I’m using GoDaddy hosting.

Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Author Michael Zangl

    (@michaelzangl)

    Hi,

    Can you have a look in the plugin directory:
    /wp-content/plugins/add-watermark

    There should be a directory named cache. Are there files in that directory?

    Yes there are files generated there..

    Hi do you have any idea why its slowing down the site? the htaccess file is there and the cache is there… any chance that caching misses and regenerates it everytime?

    Plugin Author Michael Zangl

    (@michaelzangl)

    I did not have time to look into it. My first guess was a problem with the write permissions for that directory. But since this is not a problem, there might be a problem with your servers mod_rewrite.

    It is hard to debug what mod_rewrite does. I guess GoDaddy does not allow you to change any configuration files. This script is tested on 1und1 hosting and some other hosters.

    What you can do to check if the cache is used: Load a image (only the image), then change something in the plugin to make it not compile (just add some garbage at the end of the file), then load that image again. If you see the error, we can try to debug the .htaccess-End. If you don’t, your hoster is slowing down requests that got redirected by .htaccess and there is nothing we can do (which I have not experienced for now)

    For the .htaccess-Problems: It could be possible that the base directory of your hosting is not detected correctly. Can you have a look into the .htaccess-file that is generated and see if the f-Rule has the correct directory specified?

    It’s giving me the error on the php side. I also checked with the debug parameter set to true. Inside the php getCachePath() it returns true and returns the file afterwards. I think that could be why its slowing things down, it goes to the php after failing to grab the file in .htaccess

    Then I inspected the htacess file as well. It’s detecting the base directory correctly (it detects what godaddy mentions on the hosting accout) but still doesn’t return the file straight away. I’m not familiar in .htacess rules. Could you see if there is something wrong here. This is my htaccess file (I redacted the absolute path).

    ### WATERMARK START
    RewriteEngine On
    RewriteBase /wp-content/uploads/
    RewriteCond /home/content/x/x/html%{REQUEST_URI} -f
    RewriteCond $0 ^/?(.*\.(jpe?g|png))$
    RewriteCond /home/content/x/x/html/wp-content/plugins/add-watermark/cache//%1 -f
    RewriteRule (.*) /wp-content/plugins/add-watermark/cache//$1 [L]
    RewriteCond $0 ^/?(.*\.(jpe?g|png))$
    RewriteCond /home/content/x/x/html/wp-content/plugins/add-watermark/cache//%1.nowm !-f
    RewriteCond $0 !^wpcf7.*
    RewriteRule (.*) ../../wp-admin/admin-ajax.php?action=watermark_image&path=$1 [L]
    ### WATERMARK END

    My replies are not showing up to me…

    It’s giving me the error on the php side. I also checked with the debug parameter set to true. Inside the php getCachePath() it returns true and returns the file afterwards. I think that could be why its slowing things down, it goes to the php after failing to grab the file in .htaccess

    Then I inspected the htacess file as well. It’s detecting the base directory correctly (it detects what godaddy mentions on the hosting accout) but still doesn’t return the file straight away. I’m not familiar in .htacess rules. Could you see if there is something wrong here. This is my htaccess file (I redacted the absolute path).

    ### WATERMARK START
    RewriteEngine On
    RewriteBase /wp-content/uploads/
    RewriteCond /home/content/x/x/html%{REQUEST_URI} -f
    RewriteCond $0 ^/?(.*\.(jpe?g|png))$
    RewriteCond /home/content/x/x/html/wp-content/plugins/add-watermark/cache//%1 -f
    RewriteRule (.*) /wp-content/plugins/add-watermark/cache//$1 [L]
    RewriteCond $0 ^/?(.*\.(jpe?g|png))$
    RewriteCond /home/content/x/x/html/wp-content/plugins/add-watermark/cache//%1.nowm !-f
    RewriteCond $0 !^wpcf7.*
    RewriteRule (.*) ../../wp-admin/admin-ajax.php?action=watermark_image&path=$1 [L]
    ### WATERMARK END
    Plugin Author Michael Zangl

    (@michaelzangl)

    I guess that /home/content/x/x/html/ points to http://…/ and is your wordpress-root.

    So your files are in:

    /home/content/x/x/html/wp-content/uploads/ and end with .jpg, .jpeg or .png

    And your cached files are in:
    /home/content/x/x/html/wp-content/plugins/add-watermark/cache/
    with the same directory structure.

    This is odd. I don’t see a problem with the htaccess file. You can try replacing the // with a /, but it should not make that much of a difference.

    Is your server using apache2? Are there any odd server configurations?

    If you have access to the server configuration for that vhost, you can add: LogLevel warn mod_rewrite.c:trace4 to get a detailed trace of what mod_rewrite is searching for and why it is not using that cached image.

    An other solution might be to add Options -Multiviews to the beginning of the .htaccess file.

    Ok I fixed the error in the .htacess file. It was not getting the correct path as you said. I overlooked it earlier. It should have been /home/content/x/x/mysitename/html/wp-content/plugins/add-watermark/cache. It didn’t have of my site subfolder in that url. I think plugin can be fixed to write the correct url in the writeHtAccess method. I’ll submit a PR if you have a repo. Thanks for the guidance all the way to getting it to work.

    Plugin Author Michael Zangl

    (@michaelzangl)

    The $_SERVER['DOCUMENT_ROOT'] seems to be wrong then.

    The github repo is a bit out of date:
    https://github.com/michaelzangl/add-watermark

    I’m working on the wordpress svn for now. But you can post the patch here, if you find a solution that works across other hosters.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Site slows down dramatically even after first time’ is closed to new replies.