Web Store reports being updated to 3.1.4, then offers 3.1.4 update

[jorisw]

Hi,

In the Admin panel, the 3.1.4 update is offered like so:

! New Version Alert

Web Store version 3.1.4 is now available.
You can apply this update by clicking on APPLY WEBSTORE UPDATE.

Release Notes:

(With empty release notes)

After clicking Apply Webstore Update, the progress bar finishes and I get a page saying:

Web Store update installed!

Web Store 3.1.4 is now your current version.

Then, reloading /admin/, it offers the update again like in the first quote.

If I go to System -> Latest Release Notes, it says the same as in the second quote, version 3.1.4.

[ktwbc]

Hi,

What is your current version that you're on? 3.1.3 or something earlier?

[jorisw]

From what I recall, we've always kept up to date so I would assume 3.1.3, but I don't know how to verify that now that WebStore reports that it's at 3.1.4.

However, these are the contents of core/protected/config/wsver.php if that helps:

<?php

define('XLSWS_VERSION', '3.0.7');
define('XLSWS_VERSIONBUILD', 3070);
define('XLSWS_BUILDDATE', '2013-10-29 12:09:18');

[jorisw]

Update: After chmodding the webstore installation to 0777 recursively, the web store successfully updates to 3.1.4, and 3.1.5 thereafter. I know 0777 is not good and I'm looking for a way to set the file owner instead.

The only bug then seems that it shouldn't report success on an update that actually failed because of permission problems.

The contents of core/protected/config/wsver.php now are:

<?php

define('XLSWS_VERSION', '3.1.5');
define('XLSWS_VERSIONBUILD', 3150);
define('XLSWS_BUILDDATE', 'webstore-2014-04-24-2336');

[ktwbc]

As of this date, it should now flag to go to 3.1.6. If you reopen Admin Panel, are should be prompted. (PS, you can turn on Auto Update via Admin Panel->System->System Configuration if you wish. We turned it off for the 3.0 to 3.1 upgrade but that was a one-time event.)

As for permissions, no you should not have to open it up to the world. It sounds like that the permissions the Apache Virtual Host are running under aren't part of the group your web store folder is set for, or some other sort of mismatch of permissions where it does not have write access. Normally the reason we have people download the initial install.php and that file in turn (running under Apache) installs the rest of the store is so Apache writes all the initial files with the permissions it needs.) In any case, your security settings may need to be adjusted to allow Apache/PHP write access without having to open it that wide.

(You can test on the /assets folder by deleting the random subfolders there, set restrictive permissions on /assets and then go to the Web Store home page. If it errors out, change permissions until Apache can write but still not being open to the world. This may involve evaluating your security model between Apache and your install folders. Once you've figured the settings, apply those to web store as a whole and that should work.)