locked
Wincache 1.1 and Wordpress plugin problem RRS feed

  • Question

  • User364688331 posted

     I've been having a problem with Wordpress and it seems to be caused by wincache. Several others have reported the same problem on the Wordpress.com forums

    Essentially what happens is when attempting to upgrade a Wordpress plugin, the upgrade fails with a message similar to this -

    Unpacking the update.
    Installing the latest version.
    Deactivating the plugin.
    Removing the old version of the plugin.
    Could not create directory. DIRECTORY\wwwroot/wp-content/plugins/akismet/
    Plugin upgrade Failed.

    I'm running Wordpress 2.9.2 on a Windows 2008R2 VPS, with PHP 5.2.13 and wincache 1.1

    Checking on the VPS, the plugin directory is there but inaccessible even as an administrator, with "access is denied". Restarting IIS results in the folder disappearing. The plugin can then be installed.

    Clearly there's some locking problem occurring somewhere. Disabling wincache stops the problem.

     

    Wednesday, July 21, 2010 6:38 PM

All replies

  • User-1405480850 posted

    Thanks for reporting. We are looking into this and will update this thread once we know the reason.

    Regards,

    Don.

    Wednesday, July 21, 2010 7:20 PM
  • User364688331 posted

     Thanks. I should have noted I was using object-cache.php 0.1 also.

    Wednesday, July 21, 2010 7:38 PM
  • User-1405480850 posted

    Hi,

    Can you clarify few things:

    • Are you seeing this with behaviour with only object-cache.php present? Or presence of object-cache.php doesn't matter?
    • Did you see this problem with older versions of WINCACHE like 1.0.0, 1.0.1 or you are seeing it only with WINCACHE version 1.1?

    Thanks,

    Don.

    Wednesday, July 21, 2010 7:54 PM
  • User364688331 posted

     I've had the problem for a while but not had time to worry about it, I suspect it was introduced with the 1.1beta when I installed it. Disabling wincache for the site in php.ini seemed to stop this particular problem. I was still having problems with plugin installations reporting "plugin does not have a valid header" though so I've just upgraded my site to Wordpress 3.0 and that problem is gone. I haven't renabled wincache for the site as others on the thread reference above report it happening with WP3.0 also. None of them mention object-cache.php so they either (like me) forgot completely about installing it, or they're not using it. I only remembered it because the new WP3.0 dashboard reported it's presence.

     

     

    Wednesday, July 21, 2010 8:05 PM
  • User-1444643443 posted

    login to wincache.php and click "Clear All" under ucache tab. Plugin will install and run properly now.

     

    My prob with uscahce is getting it to obey TTL settings

    Tuesday, August 3, 2010 2:51 AM
  • User-1405480850 posted

    Thanks Hayden. This is a good workaround. However we are working on a fix.

    Don.

    Tuesday, August 3, 2010 2:57 AM
  • User-1490159686 posted

    Same Problem here (Win 2008 R2)

    Wincache, Wordpress & same file / folder behaviour.

    Deactivating the PlugIn solves the problem. A update woul be great,

    Monday, August 9, 2010 6:06 PM
  • User-1405480850 posted

    A bug has been filed at http://pecl.php.net/bugs/bug.php?id=18010. And we are actively working on a fix.

    Thanks,

    Don.

    Monday, August 9, 2010 7:21 PM
  • User-1405480850 posted

    Hi,

    I just had a conversation with the developer and as guessed WINCACHE file change notification feature is causing the problem. So another workaround is to disable wincache file change notification. Just set wincache.fcndetect=0 in your php.ini file. Details about this directive can be found at http://us2.php.net/manual/en/wincache.configuration.php#ini.wincache.fcndetect.

    Thanks,

    Don.

    Monday, August 9, 2010 7:55 PM
  • User-1405480850 posted

    Hi,

    We believe we have a fix for this. We tested this on our end and the problem seems to go away. I would like everyone reporting this problem to test the private bits. Here is the link to private bits:

    If you are using PHP5.2 use the link - http://sourceforge.net/projects/wincache/files/development/wincache-1.1.1-dev-5.2-nts-vc6-x86.exe/download

    If you are using PHP5.3 use the link - http://sourceforge.net/projects/wincache/files/development/wincache-1.1.1-dev-5.3-nts-vc9-x86.exe/download

    MD5 hash for the both the downloads are available at - http://sourceforge.net/projects/wincache/files/development/wincache-1.1-dev-md5.txt/download

    SHA1 hash for both the downloads are available at - http://sourceforge.net/projects/wincache/files/development/wincache-1.1-dev-sha1.txt/download

    I would strongly encourage all of you to try this out and leave the feedback here or email me at don.raman@microsoft.com.

    Thanks,

    Don.

    Tuesday, August 10, 2010 10:07 PM
  • User-1490159686 posted

    Hi Don,

    i have tested the file. But in my case there was a new problem.

    When i use the new dll and restart the iis, the page is not responding (the browser is waiting for an answer from the webserver). In my case i'm using the paramter "wincache.maxfilesize=512".

    I have tried it without the paramter and it was working for one call. When i activate the parameter again the first load was okay. But then the page was not answering at the second call.

    Because it's a production server i wasn't able to do some more testing...  I have switched back to the old version.

    I'm using PHP 5.3.3 / Win 2008 R2 / Wordpress 2.9.2

    Thursday, August 12, 2010 2:34 PM
  • User-1490159686 posted

     Something new? Anybody else got this problem?

    Thursday, September 2, 2010 7:14 AM
  • User-1653247517 posted

    Hi,

    So this seems a bug in maxfilesize and has nothing to do with wordpress plugin upgrade problem. Can you start a separate thread for this? I understand plugin upgrade problem is fixed with the private.

    Thanks,
    Kanwal

    Thursday, September 2, 2010 12:45 PM
  • User-1653247517 posted
    Hi,

    We have uploaded test build of WinCache 1.2 release at http://sourceforge.net/projects/wincache/files/. This build should not have problem with maxfilesize and also with wordpress upgrade. Pls try it out and let me know if you see any problem.

    Thanks,
    Kanwal
    Friday, September 24, 2010 9:58 PM
  • User1828779420 posted
    Hi Kanwal, I'm using the latest build from sourceforge, and still experiencing the problem.
    Tuesday, October 19, 2010 4:29 PM
  • User961784352 posted
    Hi, Any update on when a fix for this could be available? We're also having this problem, it makes the folder of any plugin that we try to upgrade completely inaccessible (have to run a chkdsk to make that folder accessible again). Wincache is amazing, super fast and stable, this is the only problem we have with it, would love to have it fixed. Thanks. Mos
    Thursday, December 2, 2010 8:07 PM
  • User-1918935842 posted

     Hello,

    can someone else confirm that dev 1.2 version fixed/not fixed this issue?

    Tuesday, December 7, 2010 7:33 AM
  • User69723610 posted

    I have been silently following this thread and until now nothing has worked for me. I have upgraded to WinCache 1.2 and no longer have the WordPress update problem.  If ver 1.2 didn't fix it for you then maybe you downloaded the wrong file (which is what I did the first time).  After you click the above link for ver 1.2, you have to click on development.

    Thanks for the working update!

    Saturday, December 11, 2010 4:06 PM
  • User961784352 posted
    Thanks csanders, but I just tried it and still getting the error. I downloaded the 1.2 5.3 vc9 version at http://sourceforge.net/projects/wincache/files/development/wincache-1.2-dev-5.3-nts-vc9-x86.exe/download I installed it, recycled my iis app pool and then loaded the wincache.php to verify I was running wincache 1.2 (it shows WinCache version 1.2.924.0, with php 5.3.3) I am still getting the same errors when trying to upgrade a plugin from wordpress, I end up with corrupted security settings on the folder of the plugin and it can't be accessed again until I run a chckdsk. Are you also running 1.2 with php 5.3.3?
    Sunday, December 12, 2010 8:51 PM
  • User69723610 posted

    Hey Mmos, I'm running PHP 5.2.14, so I downloaded the version for 5.2.

    Sunday, December 12, 2010 9:14 PM
  • User-1653247517 posted

    Hi,

    1.2.924.0 build had an incomplete fix to this problem. We have complete fix which is working well. We will upload new privates to sourceforge share soon and update this thread.

    Thanks,
    Kanwal

    Monday, December 13, 2010 1:42 AM
  • User1994556403 posted

    Are there any disadvantages of setting wincache.fcndetect = 0 and wincache.chkinterval to 1 (second) for example? Because you'd want changes to your code to be picked up as soon as possible.

    When someone doesn't want to disable wincache.fcndetect users can always disable file- and (or) opcode caching in their scripts. Either by using a .user.ini file for PHP:

    wincache.fcenable = 0
    ;wincache.ocenable = 0

    or by using the ini_set()-function of PHP:

    ini_set('wincache.fcenable','0');
    //ini_set('wincache.ocenable','0');

    Setting this in /wp-admin/includes/admin.php is a good idea, but after updating the Wordpress core, the change is gone.

    Regards,
    Jan Reilink

    Monday, December 13, 2010 8:05 AM
  • User961784352 posted
    Thanks Kanwal! Looking forward to testing it. Were the errors specific to php 5.3.x? (csanders is on php 5.2.x and it seems to work for him)
    Tuesday, December 14, 2010 10:25 AM
  • User69723610 posted

    I do still have some issues while updating wordpress plug-ins, I'm just not sure if they're still related to Wincache.  Sometimes I will get a internal server error 500 after updating and have to restart IIS to get it working.  Also, every time I update a plug-in, wordpress will say it's downloading the update and will never move on from downloading.  Once I click away and check the plug-in folder I see that the plug-in was updated.   But no matter what errors or issues I have while updating, the plug-in folder gets deleted when it should and there are never permission issues on the folder so maybe these issues are more related to wordpress itself or something else.

    Tuesday, December 14, 2010 1:07 PM
  • User961784352 posted
    I've narrowed down the error condition, if a php file is currently opened and the folder it is in is deleted on the server then that folder ends up corrupted and completely inaccessible (can't reset the owner or permissions) and a chkdsk is required to fix the problem. Overwriting an existing php file or whole folder (instead of deleting) seems to be ok.
    Friday, December 24, 2010 2:50 PM
  • User961784352 posted
    doing an iisreset also fixes the problem (a recycle pool on the app pool doesn't work for us)
    Monday, December 27, 2010 12:52 AM
  • User-1637866776 posted

    The latest development build with this attempt to fix this bug has been published here:

    For PHP 5.3 http://sourceforge.net/projects/wincache/files/development/wincache-1.2.0-dev-5.3-nts-vc9-x86.exe/download

    For PHP 5.2 http://sourceforge.net/projects/wincache/files/development/wincache-1.2.0-dev-5.2-nts-vc6-x86.exe/download 

    All who have run into the bug with Wordpress plugin upgrades - can you please try this build and report if the problem still exists?

     

    Tuesday, January 4, 2011 6:57 PM
  • User69723610 posted

    I tried the 5.2 version and now I'm back to getting "Access is denied" when I try to access the plug-in folder.  Once I restart IIS the folder gets deleted and I can re-install the plug-in.

    Tuesday, January 4, 2011 7:28 PM
  • User-1637866776 posted

    Just to confirm - do you use the WordPress object cache as described in this article: http://ruslany.net/2010/03/make-wordpress-faster-on-iis-with-wincache-1-1/ 

     

    Tuesday, January 4, 2011 7:43 PM
  • User69723610 posted

    I don't have a file called object-cache.php in my wp-content folder so it doesn't look like it.  I've never set it up that way, should I have?

    Tuesday, January 4, 2011 7:57 PM
  • User-1637866776 posted

    No, you should not have if you don't want to. I used that on my wordpress site and I thought that may be this was causing the problem with plugin upgrades. It looks like the bug repros even without using wordpress object cache. Good to know.

    Tuesday, January 4, 2011 8:15 PM
  • User-1637866776 posted

    I am able to consistently repro this bug on PHP 5.2. I am not able to reproduce this with PHP 5.3. It looks to me that this is a problem specific to PHP 5.2. Has anybody run into this with PHP 5.3?

    Wednesday, January 5, 2011 7:48 PM
  • User961784352 posted
    I will test with php 5.3 in the next few days and report back here Thanks for the update
    Thursday, January 6, 2011 8:43 AM
  • User-1637866776 posted

    Nevermind, I was able to repro this with PHP 5.3.4 today. So the problem is not specific to a PHP version.

    Thursday, January 6, 2011 3:03 PM
  • User1994556403 posted

    Mmos & csanders:
    Sounds like a PENDING DELETE thread on the file or directory, but IIS keeps the file "in use" and it can't be deleted. Therefor, doing a iisreset releases the lock and the pending delete is executed. Recycling the application pool does (should) release the lock.

    Ruslany:
    Last week we upgraded to PHP 5.3.4 and Wincache 1.2.x, development release. We turned file caching off: wincache.fcenabled=0 in php.ini. We found in our testing that the specific bug was not resolved, when leaving fcenabled to 1 (enabled).
    Clients are now forced to turn this setting on in a user.ini file, if they want to use Wincache's file caching mechanism. This solved most of our customers problems with updating Wordpress plug-ins. Some still report update failures, which we're trying to reproduce.

    I'll post my findings.

    Wednesday, January 19, 2011 3:36 AM
  • User69723610 posted


    Mmos & csanders:
    Sounds like a PENDING DELETE thread on the file or directory, but IIS keeps the file "in use" and it can't be deleted. Therefor, doing a iisreset releases the lock and the pending delete is executed. Recycling the application pool does (should) release the lock.

    This is exactly what I think as well, just not sure what to do about it.  as Mmos said recycling the app pool doesn't work, iisreset does. For now I just turned WinCache off but I'll continue to try any new versions that are released.

    Wednesday, January 19, 2011 9:29 AM
  • User364688331 posted
    I just wanted to confirm I'm still having this problem on both Wordpress and Joomla, using the latest wincache 1.2dev version. A recycle of the appropriate app pool allows me to delete files.
    Tuesday, February 15, 2011 9:15 AM
  • User-917625502 posted

    We are too, got about 10 - 15 tickets a day about not being able to delete PHP files, not even related to WP, Joomla sites, custom developed systems etc. all have the issue.

     I finally disabled WinCache, its a nice system, but has some issue that apparently even after what 6 months... Microsoft's team cannot fix this issue. As far as I am concerned Wincache is a dead product.

    http://pecl.php.net/bugs/bug.php?id=18010 the last update on was Jan 20th. It's now nearly April and still nothing, no updates, no activity, this product is dead.

    Saturday, March 19, 2011 12:28 PM
  • User364688331 posted
    It would seem so, which is such a shame. It makes a HUGE difference in speed, particularly with my mediawiki site. Any recommended alternatives?
    Saturday, March 19, 2011 1:02 PM
  • User-541044535 posted
    Hey Echodreamz, you don't need to disable wincache altogether, the workaround to disable the FCNotify for now should work. Whilst I agree its not ideal, it won't take you back to the performance you're experiencing when you disable wincache altogether. Jason.
    Monday, March 21, 2011 1:35 AM
  • User-2048372337 posted

    What is FCNotify? I can't find the documentation on that.

    Monday, March 21, 2011 9:00 AM
  • User-541044535 posted
    oops haha I was a bit too quick for myself... It's the FC Notify Detect which is used to detect changes to the file system as far as I'm aware. Here is my current WINCACHE settings in the PHP ini. Also due to some issues with a few of our old websites, we also had to change the session.save_handler from "wincache" to "files" for now (this might have something to do with output buffering, we're not 100% sure at this stage). [PHP_WINCACHE] extension=php_wincache.dll wincache.fcenabled=1 wincache.fcndetect=0
    Monday, March 21, 2011 9:14 AM
  • User-2048372337 posted

    Ah, ok, thought you were referring to some feature I was unaware of.

     Yes, we can't use the session cache either.

    Monday, March 21, 2011 9:20 AM
  • User-1637866776 posted

    I have just published a new development build of WinCache for PHP 5.3 with the fix for the wordpress plugin upgrade bug (http://pecl.php.net/bugs/bug.php?id=18010)

    Please install it from this location and let me know if the bug still repros or if it works for you:

    http://sourceforge.net/projects/wincache/files/development/wincache-1.2.329-dev-5.3-nts-vc9-x86.exe/download

    Tuesday, March 29, 2011 4:19 PM
  • User-1490159686 posted

     Hi ruslany,

    which version is the latest to test? The 1.2.329 or the 1.2.331 in the first posting? I am a little bit confused now about the two diferent version numbers.

    Tuesday, April 5, 2011 3:21 AM
  • User-1637866776 posted
    Use 1.2.331.
    Tuesday, April 5, 2011 12:54 PM
  • User961784352 posted
    Has anyone tried 1.2.331 and see if it fixes the problem and is stable? haven't had a chance to test it yet, but will probably do it on a production system in the next week or two.
    Saturday, April 9, 2011 8:00 PM
  • User-917625502 posted
    Been running it for about a week now with no issues on PHP v5.3. Clients have not complained at all (we silently updated it to make sure clients didnt have a bad taste from previos issues with Wincache). So far so good!
    Sunday, April 10, 2011 11:07 PM
  • User-1918935842 posted
    Did you configured Wincache in php.ini or you have added only extensions entry? I've enabled latest Wincache with PHP 5.3.6 and few of higher viewed websites just stuck after some time (5-10hours froum enabling) and they where loading on client side indefinitely
    Monday, April 11, 2011 3:52 AM
  • User-1637866776 posted

    Just replacing the extension should be enough. Do you know which PHP apps those sites run? Are the sites always stuck or they mostly work but sometimes get stuck?

    Monday, April 11, 2011 12:37 PM
  • User-1918935842 posted
    Apps: Wordpress MU 3.1 (I'm not sure but it looks like it is now the same as Wordpress but different configuration) Joomla 1.5.x I'm not sure but it looks like sites stuck randomly after few hours of working. Killing app pool allows them to run again but they stuck again eventually. I was observing app pools cpu and mem usage and during "stuck time" they are idle.
    Monday, April 11, 2011 12:56 PM
  • User-917625502 posted

    Yep. I can now confirm this as well. We have 4 reports. 1 WP site, 1 XOOPS and 2 phpbb forums.

    Monday, April 11, 2011 1:49 PM
  • User-1637866776 posted

    I think I know what is causing this. I have produced a new build that should fix this bug. Can you please try it out and let me know if problem is gone or still repros:

    For PHP 5.3: http://sourceforge.net/projects/wincache/files/development/wincache-1.2.411-dev-5.3-nts-vc9-x86.exe/download

    For PHP 5.2 http://sourceforge.net/projects/wincache/files/development/wincache-1.2.411-dev-5.2-nts-vc6-x86.exe/download 

    Monday, April 11, 2011 2:09 PM
  • User-1918935842 posted

    Runing wincache for almost 3 hours and so far so good.

    EDIT: 8 hours and still working correctly and no support tickets.

    Tuesday, April 12, 2011 6:23 AM
  • User-1637866776 posted
    Good! Please also check the application event log from time to time to make sure there are no errors reported about php-cgi.exe process existing unexpectedly.
    Tuesday, April 12, 2011 12:17 PM
  • User-1918935842 posted

    On one of my IIS servers I've found this:

    Faulting application name: php-cgi.exe, version: 5.3.6.0, time stamp: 0x4d81eb28
    Faulting module name: php_wincache.dll, version: 1.2.411.0, time stamp: 0x4da33b73
    Exception code: 0xc0000005
    Fault offset: 0x0000a431
    Faulting process id: 0x6e10
    Faulting application start time: 0x01cbf9199248bc4c
    Faulting application path: C:\...PATH...\PHP\php-cgi.exe
    Faulting module path: C:\...PATH...\PHP\ext\php_wincache.dll
    Report Id: d1f4431c-651f-11e0-aee3-000c29e8e15d

     Faulting application name: php-cgi.exe, version: 5.3.6.0, time stamp: 0x4d81eb28
    Faulting module name: php_wincache.dll, version: 1.2.411.0, time stamp: 0x4da33b73
    Exception code: 0xc0000005
    Fault offset: 0x0000a431
    Faulting process id: 0x3350
    Faulting application start time: 0x01cbf8eecfab870f
    Faulting application path: C:\...PATH...\PHP\php-cgi.exe
    Faulting module path: C:\...PATH...\PHP\ext\php_wincache.dll
    Report Id: 5249383d-64e6-11e0-aee3-000c29e8e15d

    but it has occured only twice after enabling wincache.

    On another server I'm getting this:

    Faulting application name: php-cgi.exe, version: 5.3.6.0, time stamp: 0x4d81eb28
    Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
    Exception code: 0xc0000005
    Fault offset: 0x00000000
    Faulting process id: 0x1b3c
    Faulting application start time: 0x01cbf911956d2678
    Faulting application path: C:\...PATH...\PHP\php-cgi.exe
    Faulting module path: unknown
    Report Id: d469e138-6504-11e0-b562-000c291e30e7

    and this error occured about 20x times today. I'm not sure if it is related to wincache since there is "unknown" in module name. In all cases I have the same php.ini and the same environment (IIS 7.5 Win 2008 Web Server x64 with app pools set to 32 bit compatibility).

    Tuesday, April 12, 2011 12:29 PM
  • User-1637866776 posted
    Hi GrZeCh, I am trying to figure out what is causing this error. I have sent you a private message with more details.
    Tuesday, April 12, 2011 1:25 PM
  • User-1637866776 posted

    The latest build that fixes this error is available:

     http://ruslany.net/2011/04/wincache-and-wordpress-plugin-upgrade-problem/

     Thanks to GrZeCh for helping out with testing the fix!

    Thursday, April 14, 2011 7:55 PM
  • User-1490159686 posted

     Hi,

    the problem seems to be solved and the new version is running withou any errors (IIS 7.5).

    But i still have some problems when updating plugins:

    - i click on update

    - the next page shows "loading files"

    But then nothing happens, the page is stop working. I must reload the plugin page and must re-start the plugin because it's updated but noch activated.

    Somebody else here with this problem?

    Sunday, July 10, 2011 6:09 AM
  • User1621377857 posted
    I had recently (about 2 weeks ago) download the dev version of wincache due to this issue. I am using 1.2.614 for php 5.3. I am running it on a QA server right now, and it fixes the problems and has not caused any other issues. However, the load on this box is nowhere near what my production server gets. Is there a timeline to get 1.2 released? I did see that there had been some issues, but the 1.2.614 build seems to have been posted after that. I am willing to do more testing on this, please let me know where the current issues are.
    Monday, September 12, 2011 8:24 AM
  • User-917625502 posted

    I am not too sure, but it seem Wincache is dead once again. Almost 3 months have passed without even a hint of an update :(.

    Monday, September 12, 2011 5:42 PM
  • User525969356 posted
    The latest dev releases (both 1.2.614 and 1.2.427) *do not* work for me on IIS 6 and PHP 5.3 nts. I haven't tried with Wordpress, but I still see the same issue with Drupal 7. It does seem to be better, however. Before upgrading to the dev version of wincache, the Drupal folders/files being upgraded were completely locked and you could not delete/read them via Windows Explorer without recycling the app pool. Now, they are deletable immediately, but the upgrades still fail, saying 'could not remove directory...'
    Thursday, October 20, 2011 1:13 PM
  • User-1295539648 posted

     I am running WinCache for PHP on IIS7.5 with PHP 5.3.9 and WordPress 3.3.1 installed.

    Obviously, the latest official 1.1 release of WinCache causes WordPress plugin upgrades to fail.

    On this server, dev version 1.2.427 does work and solves the plugin upgrades problem.

     Dev version 1.2.614 also seems to work well.

     However, dev version 1.2.1208 does not work; the plugin upgrades problem appears with that version.

     

     

    Wednesday, January 18, 2012 3:15 AM
  • User-1672167363 posted

    Hello,

    I you need help with problems for "Wincache 1.1 and Wordpress plugin problems"

    Please file a Bug Report  https://bugs.php.net/how-to-report.php  Pecl section http://pecl.php.net/bugs/bug.php?id=18010

    and include the version information for what works or fails.

    Regards,

    Martin

     

    Wednesday, January 18, 2012 3:34 AM
  • User-1295539648 posted

     I filed the bug report but have seen no response so far.

    Tuesday, January 31, 2012 12:57 AM
  • User-1672167363 posted

     Hi thriven,

    Sorry for the late reply,

    I checked the PHP-"Bug- #59352-WordPress plugin updates do not work with WinCache object-cache.php"

     version for  "wincache 1.1" is what to use.

    PHP-Bug #59352  "https://bugs.php.net/bug.php?id=59352"

    Thanks for posting the reports.[ 2012-01-18 ] for wincache pecl extension.

    I am wating also for the status.

    Regards,

    Martin

     


     

    Saturday, February 4, 2012 9:20 AM
  • User-541044535 posted

    Ummm hate to be devils advocate here, but seriously this issue has been on and off for over 18 months and there's still no resolution?

    First I'd like to ask why this is such an issue. Second I'd love to know when there's a release version that is stable and we can all use?

    Prior to this issue we were seeing about 30% improvements on our websites. Since then we have had to allocate other resources (as you can imagine, 18 months has passed and we've grown our business more than 30% during that time).

    Now after following this thread for so long, I'm

    a) not sure which build, despite development build, is usable

    b) perplexed that we dont have a solution; and

    c) confused as to why this is now being reported as a PHP related issue!

    I'm sure I vouch for a lot of others on this thread that would agree. Moreso, I'm sure there are plenty others who don't understand the performance benefits WinCache provide because it has never worked for them (so they don't know what they're missing :))

    If someone could give me, us and the community an update as to where development of this plugin stands, then that would be great.

    Jason.

    Saturday, February 4, 2012 1:02 PM
  • User-1426524422 posted

    Dev version 1.2.614 worked for me (wincache-1.2.614-dev-5.3-nts-vc9-x86.exe). I am running WinCache for PHP on IIS7.5.7600.16385 on Windows Web Server 2008 R2 version 6.1 (Build 7601: Service Pack 1) with PHP 5.3.13 and WordPress 3.4.1 installed.

    I had inconsistent results with plugins updating properly - some did, some didn't. There were a few that always failed, in particular Gravity Forms. The tmp file was left hanging in the upgrade folder and the gravity form folder in the plugins folder was locked. After a while it would disappear and I would need to unzip the plugin manually for each site.

    With the update to 1.2.614 I was able to successfully update every plugin on my sites using the WordPress admin gui. I'll keep testing. Can someone recommend the next upgrade? There are a bunch of files in the wincache-1.3.4 folder at http://sourceforge.net/projects/wincache/files/

    Wednesday, August 8, 2012 2:23 PM
  • User409000176 posted

    Wincache 1.3.4 is explicitly for PHP 5.4 support.  It will only work with PHP 5.4.

    The latest wincache that works with PHP 5.3 should be wincache-1.2.1209-dev-5.3-nts-vc9-x86.exe (in the development folder).

    Thx!

        --E.

    Wednesday, August 8, 2012 4:55 PM
  • User-1426524422 posted

    Thanks!

    Friday, August 17, 2012 11:17 AM