active/inactive icons not updating on click (.12b1)

[kermit]

in admin interface, content -> pages

if you click a checkmark or X to toggle the active status of a page, the icon does not get updated until the next page load (either going back to content -> page), or by toggling another page's status (which has the effect of changing the previous change's icon, but not the one you just clicked; so if you're going down in order, the icon change is always one step behind).

this behaviour is not observed in layout -> templates which has a similar active status icon.

checked in both ff 1.5 and ie6sp1 (ie also has a wierd behaviour of sometimes dumping you back to the admin index and "losing" the stylesheet temporarily).

cmsms 0.12.beta1 on Apache/2.0.55 (Win32) DAV/2 PHP/4.3.11 and MySQL 5.0.17

[Ted]

Very strange.  I know why this wouldn't work (content cache), but I thought that I fixed ti so the cache isn't used in the admin.

Trying to recreate locally and it's not doing it.  Anyone else?

[kermit]

welp, i fired up vpc and copied my sandbox server to a different install of winxp, and it does the same thing in there.. with ie7 beta2 preview  (eww. yuk)

at any rate, i suspected it might be something related to the always enjoyable win32 platform, so i fired up the big guns over here, my breezy desktop, running:

Apache/2.0.54 (Ubuntu) PHP/5.0.5-2ubuntu1.1 mod_perl/2.0.1 Perl/v5.8.7 with MySQL 4.0.24

and..... it's ok !

if you care to examine the win32 server's configuration; it's the default settings (with php memory limit increased a bit) of the wampp package from www.uniformserver.com (their version 3.3 with php4 swapped in). maybe there's something in there goofing things up a bit.

i do not have a production server with windows server & php/mysql on it to properly test the win32 platform.

[Ted]

Ok, I believe I have this one figured out, though since I've never seen it, I'm not totally sure.

Please test svn when you get a chance.  Thanks.

[kermit]

sorry been wrapped up in other things the last couple days.

had problems getting daily downloaded 5 feb 19:00 est to upgrade existing beta1 test installs. dunno what is going on, just gives 'site down' message on the front end but the admin area still works.  even when using a 'fresh' install but copying config.php (and modifying it to use correct paths & use an existing db). will fetch the next one and try again.

[kermit]

did you run install/upgrade.php ?
also go look in admin global settings, if "site down for maintenance" is checked.

tried with and without running the upgrade script and no, the 'site down' option is not checked. plus, as i mentioned, i also tried it on a new directory with the daily extracted to it, copying over just the config.php (edited to match the new paths and to use existing db).


is the 'site down' message configured to be displayed on any particular errors in the code or configuration? if so, is there a way to enable the display of the reason for disabling the site?

[Ted]

The site down message is a "feature" for upgrading.  Basically, when you overwrite your old one, it creates a file in tmp/cache called SITEDOWN.  This is so people aren't looking at a messed up site while you do the upgrade.  After you complete the upgrade script, it SHOULD remove that file.  Double check and make sure it isn't there.

[kermit]

The site down message is a "feature" for upgrading.  Basically, when you overwrite your old one, it creates a file in tmp/cache called SITEDOWN.  This is so people aren't looking at a messed up site while you do the upgrade.  After you complete the upgrade script, it SHOULD remove that file.  Double check and make sure it isn't there.

yup. sure 'nuff. looks like a permissions problem. the file was extracted with 755 permissions and owned by the user that extracted the archive. in this case, it was root that extracted the files, so the web server (user www-data) could not remove the file. same thing would happen on a shared environment with a non-root user.

so, you need to change permissions or ownership of the SITEDOWN file (which is in the distribution archive) after extracting the upgrade, and before running the upgrade script in order for it to be able to remove it automatically.

an appropriate note should be added to http://wiki.cmsmadesimple.org/en:installation:upgrading and in the docs included with the distribution; and perhaps the upgrade script could notify the upgrader when the SITEDOWN file could not be removed automatically.

[Ted]

Hmm.  That's quite a pickle.  Maybe the Site Down message should mention the filename and the upgrade script should give a notice that it couldn't remove the file.

[Ted]

Can't change permissions on a file unless you're the owner or root.  So it's already too late by then.

[kermit]

no, the site down message shouldn't say anything specific. no sense advertising a potentially insecure system.

in addition to my suggestions above (notice in the upgrade script, mention in the online and archive documentation), maybe a notice in the administration area too, like the 'install directory present' notice. those items should be more than adequate to get the message across about the 'sitedown' file.

also, does the upgrade script check to ensure it has write access to the necessary directories and files? like the install script does, in case the upgrade adds a path or files to the system that should be writable by the server.

you can embed permissions into a tarball, and preserve them on extraction, but that would present it's own problems.

patricia: the upgrade script doesn't create the (sitedown) file, it's present in the distribution archive itself.

[calguy1000]

On the roadmap for 1.0 is a new installer which will address these problems.
the biggest idea, is to have the user install a cms_install.php (or something like that), and when he browses to that, it would then ask him all of those funky questions, and automatically install eveyrthing from a central location (or mirror). 

though this would have it's own difficulties (i.e: the permissions of all of the files would be owned and writable by the httpd daemon process), it would help with the problem of missing files, and permissions issues on install.

[kermit]

On the roadmap for 1.0 is a new installer which will address these problems.
the biggest idea, is to have the user install a cms_install.php (or something like that), and when he browses to that, it would then ask him all of those funky questions, and automatically install eveyrthing from a central location (or mirror). 

while that's a nifty idea, do not abandon the traditional 'self-contained' distribution archive that does not need to fetch any files from a remote location.

[kermit]

hey all.  been away for a bit, and still not quite "here" yet.. but anyway,

the behaviour described in the original post still exists in beta2. changing the status of a page doesn't refresh that entry's icon right away, you need to refresh or toggle another status to get the previous one to change.

current server i'm working with is an rhel clone running apache 1.3.34, php 4.4.1, and mysql 4.0.25. and for a change, it's not my box. finally broke down and got a normal account somewhere to offload some of the hassles.

client is firefox 1.5.0.1 or ie 6.0sp2 on winxp.

will try out the latest svn when i get a chance to fire up my own linux box again.

[Ted]

i'm still not getting this now.  I thought I fixed it earlier, but I don't remember if it was before or after beta2.