CMS Made Simple Forums

Nope, and Nope.... The frontend wysiwyg is just so that people who have permission to enter questions, or to add news articles without logging into the admin area will get a wysiwyg

Hello,

publishers of 1.2, please take care of the release notes. All previous upgrades have their sets of confused users who don't know which package to download (total ? diff ?) and which upgrade procedure to follow ("there is no upgrade.php in my diff...")

I'd like to see a table like this in the release notes :
Installing/upgrading to CMSms 1.2

From scratch
(no previous installation)download linkInstallation procedure
From 1.1.2download linkUpgrade procedure
From 1.1.1download linkUpgrade procedure
From 1.1download linkUpgrade procedure
From 1.0.xdownload linkUpgrade first to 1.1

and remember to always backup (files+database) before upgrading.

I think users should like it

Pierre M.

Excellent idea, Pierre. I like the sound of that very much.

Pierre,

I like the idea of a table-type list, but I think it can even be more simplified. If a little mark is set in the table, reflecting a DB-change, then the upgrade-script should be run, otherwise upgrading is just transferring files.

I think for the users seeing at a glance that DB-change is done, would be a gain.

Ronny

Yes, rows may be collapsed, if I understand well. Documenting somewhere which versions have which db schema is a nice idea.
I would like the "how do I upgrade from 1.0.2 ?" sort of question not show up in the support forum.

Pierre

it is my experience that not very many people read the docs anyways (they can't even find the sample .htaccess file that comes with the distribution, or the wiki that is underneath the big 'documentation' link at the top of the site page.  Your ideas to stop the silly questions in the forum are all probably just wishful thinking.

However, if you must, please submit your documentation changes either as a diff (or in this case because it's just documentation) send me the changes you recommend and I'll see about putting them in.

Calguy1000,

I agree that most people don't read the complete documentation. That is why I made the remark to show if a DB-change is applicable in that release. If in the announcement and in the downloads-menu the version is announced, with a small remark that the upgrade concerns an DB-change and thus the install/upgrade.php, everyone knows quickly what to expect.

In the download-menu, the diff is now accompanied with the text:

Upgrade 1.1.3.1 to 1.1.4.1 (works for people who have 1.1.4 also)

This sentence could state a DB-change if applicable.

Ronny

Hi All,

I agree with Pierre's idea (even if I prefer secoif's one, to handle upgrades from within CMSMS - but I don't see it too realistic anyway) but I would add that in all cases, it would be easier for the enduser to have an upgrade.php to launch;

even if it does nothing (except print "hello world, cmsms is great and the upgrading procedure went ok"), there would be only one upgrading procedure. Therefore, no need for unread documentation (even if I think some users do read documentation ), everything is handled by developpers.

Hi again,

calguy1000 wrote: ...please submit your documentation changes... I'll see about putting them in.

If I could fill the above upgrade table, I would have already done and happily posted and/or sent to you. But I don't know which package uses which db schema, which one (1.1.2?) can just overwrite which ones (1.0.x? 4<x<8?), which piece changes (ado ? smarty ?..) and which doesn't (so which files to copy over), etc. I have only seen something about "upgrading from a version previous to 0.5" in the 1.2b3 release notes.

I agree too much people don't read the release notes... but I need information to do my support task

May be I'm overseeing  and I have not realized that the 1.2 upgrade wizard is that magic, handling all cases ?

Pierre

reading this interesting topic, I was also wondering about how enduser for which I do the website could easily update without fearing destroying everything, and also without my help ?

And Pierre's proposition is a very good idea to make things clear about update.

I don't suggest end-users who don't know much about websites, etc. do the upgrading.  It should be done by somebody that knows what they're doing. 

The proper steps for upgrading are:  a) backup b) verify the backup c) copy the files overtop (either the full version or the diff, and only the proper diff (so some verification has to occur that you are upgrading from the correct version), d) run the upgrade script (if necessary).  e) clear cache f) check module compatibility, g) test

these are steps that are beyond the capabilities of most 'end users'.

Thanx for your very clear and complete answer.