cannot get this working after update.

  • Resolved WCat

    (@wcat)


    11 years ago

    Im not sure whats going on. This plugin worked great before. Now it’s complaining about file permissions I have tried everything up to and including 777. Ive removed the -linux, and then finally just copied the old OptiPNG version 0.7.4 and old LCDF Gifsicle 1.68 into a new ewww folder.

    everything reads ok
    jpegtran: OK version: Independent JPEG Group’s JPEGTRAN, version 9 13-Jan-2013
    optipng: OK version: OptiPNG version 0.7.4
    gifsicle: OK version: LCDF Gifsicle 1.68
    Graphics libraries (only used for conversion, not optimization): GD: OK   Imagemagick ‘convert’: MISSING
    safe mode: Off  exec(): OK  shell_exec(): OK  
    Only need one of these: finfo: OK  getimagesize(): OK  mime_content_type(): OK

    except…the red content warning box will not go away.
    EWWW Image Optimizer couldn’t install optipng and gifsicle in /var/www/example.com/htdocs/wp-content/ewww/. Please adjust permissions or create the folder. If you have installed the tools elsewhere on your system, check the option to ‘Use system paths’.
    it seems something is wrong. what i have no idea. This is the third attempt to update this plugin resulting in failure. Seems everythin is working I just cannot figure out why it is complaing about the ewww folder permissions.

    great plugin up till now….

    http://wordpress.org/extend/plugins/ewww-image-optimizer/

Viewing 7 replies - 1 through 7 (of 7 total)
  • Thread Starter WCat

    (@wcat)

    11 years ago

    update: reset APC cache and the settings page wanted gifsicle updated. downloaded latest version of plugin unzipped renamed gifsicle removing -linux and uploaded. That seems to have worked everything is reading ok now but the content box warning is back to

    EWWW Image Optimizer couldn’t install tools in /var/www/example.com/htdocs/wp-content/ewww/. Please adjust permissions or create the folder. If you have installed the tools elsewhere on your system, check the option to ‘Use system paths’. For more details, visit the Settings Page or the Installation Instructions.

    I also went to reoptimize a few images which failed
    content/uploads/2013/03/T4yADGa.jpg is not writable.

    Im going to restore server backup again and wait for an update. Should my image files themselves be group writable? It wasnt necessary before. I am sure this is some stupid little thing I am not thinking of.

    ps didnt mean to sound like a d-bag this is a great plugin and I have become reliant on it especially for one client. I just am a little frazzled as to why I cant get the darn thing working like it was before the update.

    jpegtran path: /var/www/example.com/htdocs/wp-content/ewww/jpegtran
    optipng path: /var/www/example.com/htdocs/wp-content/ewww/optipng
    gifsicle path: /var/www/example.com/htdocs/wp-content/ewww/gifsicle
    pngout path:
    disabled functions: pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority
    bundled jpegtran permissions: 0755
    bundled gifsicle permissions: 0774
    bundled optipng permissions: 0755
    wp-content/ewww permissions: 0775
    jpegtran checksum: e2ba2985107600ebb43f85487258f6a3
    gifsicle checksum: 44273fad7b3fd1145bfcf35189648f66
    optipng checksum: 4eb91937291ce5038d0c68f5f2edbcfd
    pngout checksum:
    user: www-data
    Operating environment: Linux 3.2.0-23-virtual #36-Ubuntu SMP Tue Apr 10 23:58:38 UTC 2012 i686

    Plugin Author nosilver4u

    (@nosilver4u)

    11 years ago

    It sounds like the files in your wordpress install do not have the correct owner, if you are having trouble even with your uploads/ folder. Make sure everything in the htdocs folder is owned by the www-data user.

    Something like this should do it:
    chown -R www-data:www-data /var/www/example.com/htdocs

    Thread Starter WCat

    (@wcat)

    11 years ago

    http://codex.wordpress.org/Hardening_WordPress
    “All files should be owned by your user account, and should be writable by you. Any file that needs write access from WordPress should be writable by the web server, if your hosting set up requires it, that may mean those files need to be group-owned by the user account used by the web server process.”

    thats from codec. user:www-data. 755 and 644, except for uploads(and wp-config.php). I self host so group ownership isn’t necessary or appealing to me.

    www-data group has read and write on wp-content/ewww folder.
    I shouldnt be seeing that warning. Restoring last version of the plugin doesnt do it. I’ll bump up the permissions on htdocs to make it writable to check but i dont want to keep my webroot owned by www-data.

    Also I dont have issues uploading.
    Thanks for the quick reply. If I am missing something I apologize for wasting your time. Ill check it out tomorrow and get back to you.

    Plugin Author nosilver4u

    (@nosilver4u)

    11 years ago

    that setup should be fine, I just generally do it differently. Especially on a server I have full control of, I make all files owned by www-data, and then adjust permissions accordingly.

    The reason (I think) that they go that route, is that php will refuse to modify any files not owned by the web user (www-data), so it is an easy method of security, but you can accomplish the same thing by just taking away write permissions.

    Anyway, the important 2 things we are looking at is the ‘ewww’ folder, and the ‘uploads’ folder.

    From my understanding, the uploads folder must be owned by www-data, in which case user-writable is fine. From the above, sounds like group-ownership will also work, but you would also need to make it group-writable as well, which sounds like that may be what you are running into with the images.

    On the ‘ewww’ folder, there could be many things happening. The most common issue is that the binaries get corrupted by ftp uploading them. They MUST be transferred in BIN (binary) mode, or it just doesn’t work. To keep your tight security, it should be sufficient to temporarily make the ewww folder 777, make sure it is owned by www-data, and visit the settings page to trigger the tool install. Once that is done, you can remove all write permissions from ewww until the next upgrade that includes new binaries. The primary thing that triggers the tool installer is a mismatch in size between the binaries in the plugin folder (ewww-image-optimizer), and their final destination (ewww). It also attempts to ensure that the tools have 755 permissions as well, so if they don’t, it will complain if it can’t fix that too.

    Ironically, I just completed some debug code on that function in the latest ‘dev’ version of the plugin. If you install that, turn on Debugging, and then refresh the settings page, there will be a fairly detailed log at the bottom of the page (in yellow, can’t miss it) that should tell us what is going on.

    Thread Starter WCat

    (@wcat)

    11 years ago

    Awesome

    I have a much better idea of whats going on now. I’ll bump up to 777 on both then try the update again. Sounds like that might do it.

    “It also attempts to ensure that the tools have 755 permissions as well, so if they don’t, it will complain if it can’t fix that too.”

    Do you mean that the binary files themselves need 755? no problem.

    Also I use http://wordpress.org/extend/plugins/ssh-sftp-updater-support/

    Sounds like this might be causing an issue too. Im not familiar with having to upload stuff in binary mode. I’ll fiddle with it in the mornin have a great weekend thank you
    Wayne

    Plugin Author nosilver4u

    (@nosilver4u)

    11 years ago

    yeah, the binaries themselves need 755.
    The ssh-sftp updater shouldn’t be a problem. I always use sftp/ssh for transferring the binaries between machines, and haven’t had an issue. As far as I know, they transfer files strictly in binary mode.

    Let me know how you fare!

    Thread Starter WCat

    (@wcat)

    11 years ago

    Mornin

    success

    I changed ownership of wp-content/ewww/ and /plugins/ewww-image-optimizer
    to www-data it all installed then I changed it back they way I had it before.

    For me I have a multisite network with 10 or so blogs in it as well as 4 or 5 individual WordPress installs. With ownership as www-data I wouldnt be able to give clients sftp access to their sites without adding them to www-data which would in turn give them access to the other blogs.

    anyway thanks for the help very much appreciated!!

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘cannot get this working after update.’ is closed to new replies.