Main development direction?

[svasti]

Hello everyone,

What main direction should the development of CMSimple_XH take?

Here is my proposition:

1. Pluginmanager
2. Put content.htm and and pagedata.php into one file
3. Development of some kind of automatic upgrading
4. Offer the choice on how to create new pages, either the traditional way through h1, h2 etc., or through some new way which allows using all headings on a page.

May be somebody has some better ideas? Visionaries and visions are welcome.

svasti

[Tata]

I am no programer. And so my opinion follows only my user's point of view.

Pluginmanager

Integration into the core might be interessant. However, all plugin authors must be aware about this.

Put content.htm and and pagedata.php into one file

I am not sure if the splitting of these files in content.htm and pagedate.php didn't speed up browsing. Also changing of the way the pages are controlled will stop the back-compatibility IMHO. How will it be then with evtl. upgrades?

Development of some kind of automatic upgrading

+1

Offer the choice on how to create new pages, either the traditional way through h1, h2 etc., or through some new way which allows using all headings on a page.

Here I am not sure. Actual way seems to me excellent. The structure is excellently visible, orientation in TOC or sitemap is also entirely comprehsible. Maybe a function "New Page" could be included in the core with a dialogue box for Page title and Page Level, evtl. also checkbox/radio for published, hidden, redirecting...

[svasti]

Hi Tata,
thanks so much for your input, which gives some importance to 2 points: pluginmanager & upgrading manager.

• A Pluginmanager will probably more or less follow what Gert has already done. Here compatibility seems to be all right.
• From the point of view of the user it seems an improved upgrading process is highest on the list. I also think this should be done.

svasti

[cmb]

What main direction should the development of CMSimple_XH take?

A very good question indeed! IMO it's important to define, as clearly as possible, the goals for CMSimple_XH and to state it's raison d'être among so many other CMSs. This has been done more than two years ago, so this list might be used as a base and be adapted to the outcome of this discussion. When it's "finished" it might be put on the CMSimple_XH website. Of course it should be reflected in the Roadmap.

And IMO we should not concentrate on CMSimple_XH as software solely, but also on the "infrastructure". Currently there are many, sometimes concurring sources of information about CMSimple_XH, what makes it hard for users to find, what they're looking for. I hope this will improve in the future.

About your ideas (I'll add some of mine at the end of the list):

1. + 1. Whether the plugin authors have to be aware of the plugin manager, depends on it's features. Those that were presented by Gert and myself, doesn't need any change to the plugins. An update availability check though, would require some information from the plugin (current version; where to look for the latest version).
2. Performance might suffer a bit, if both files were merged (though this has to be checked). And compatibility has to (and probably could) be maintained as much as possible.
   
   But anyway: the current situation is prone to error possibly resulting in desynchronization of content and pagedata. Martin suggested a while ago to use a common ID for content and pagedata. This should solve the problems, but I'm not sure how this could be implemented.
3. + 1 (at first we might concentrate on an update availability check, which should be far easier to implement. This could be added to the plugin management too)
4. I don't think, this should be implemented in the core of CMSimple_XH, as the structure of the content is perhaps one of the cornerstones of CMSimple.
   
   And well, AFAIK exactly 1 <h1> is best for SEO. This could be accomplished with a simple function. If one wants <h2> - <h6> on the page, he could use a plugin to write the page content (currently that's possible with Boilerplate_XH; that's not very elegant, but better solutions can be developed).
   

   Maybe a function "New Page" could be included in the core with a dialogue box for Page title and Page Level, evtl. also checkbox/radio for published, hidden, redirecting...

   Perhaps a simpler and faster page management plugin could cater for this. Otherwise it could be implemented for the editor(s).
5. Increasing the security of CMSimple_XH. IMO it's very important to get rid of the cleartext passwords and the dangerous $adm variable.
6. Code cleanup and merge of pluginloader to the core (with unified config and language dialogs)

Christoph

[Hugorm]

Hello

To me as an 'dummie' enduser my first priority is:
Content and pagedata together again.
This will allow me to use whatever editor-system I'm happy with together with a FTP upload. Minor editiations can be done in the CMS.

Second:
Security - no one should change my data. This is an impossible wish!.
My sugestion is to have an e-mail everytime anything is changed on the site.

Third:
Painless update.

Hugo

[cmb]

Hi Hugo,

sorry for the late reply -- I've somehow forget about your post.

Content and pagedata together again.

This might be the optimum and probably the simplest solution to ensure synchronization of content and pagedata.

My sugestion is to have an e-mail everytime anything is changed on the site.

Would it be ok, to send an email everytime somebody logs in (and out?)? This is easy to accomplish.

Painless update.

That would be very valuable -- but unfortunately it's hard to accomplish. At least I currently have only some vague ideas even if I often think about how this can be done.

Christoph

[Tata]

Painless update.

That would be very valuable -- but unfortunately it's hard to accomplish. At least I currently have only some vague ideas even if I often think about how this can be done.

Here I see two things:
1. All plugins authors should either add the "Version" variable to each actual plugin and re-offer these actualisations. It would of course require some unified plugin-header where the Version would be stated.
2. Pluginloader the would look for this Variable and in CMSimple back end would anly announce that a newer version is available. Short upgrade hints sholud then be attached to the plugin-upgrade. An automatic upgrade won't be probably possible because of FTP limitations (ownerships etc.). But even an upgrade wont't be that difficult via FTP if in the hints would be stated what - where - with which permissions shall be uploaded.
Such approach would let the enduser decide about eventual upgrade. As long as the upgrade won't solve any crucial vulnerability, incompatibility, bug etc., no upgrade would be necessary.

[cmb]

About the upadate availability check, see http://www.cmsimpleforum.com/viewtopic. ... 212#p17961. If this will be released as a plugin, we might not have to wait for XH 1.6.

An automatic upgrade won't be probably possible because of FTP limitations (ownerships etc.).

Indeed the file and folder permissions are a problem for an HTTP based update. But what's even more problematic, is how to handle files that were modified by the user. I'm not taking about changes to the proper program files, but about config, language files, stylesheets. Particularly changes in the stylesheets are probably impossible to handle automatically.

[Tata]

... but about config, language files, stylesheets. Particularly changes in the stylesheets are probably impossible to handle automatically.

Maybe similar way would be possible that is used with Translator_XH. SImply - strings different from original would be kept and new strings would be colored to be spicified..?

[cmb]

Since the introduction of default.php and defaultconfig.php in XH 1.5 that's probably not necessary. If a string is missing, it will be automatically taken from the default file. This is explained in detail in the XH-Wiki (the handling of defaultconfig.php is analogeous).

But the "defaults" don't cater for removed strings (well, actually they don't hurt much, but in the long run they should be stripped off; I believe that Translator_XH does this, but I'm not sure), but what's worse, the technique doesn't work for important changes. E.g.: when a plugin author changes the meaning of a setting and the according help text, this might go unnoticed.

Anyway, it would be nice to have the possibility to do an easy update, as it's possible with other software too (e.g. Firefox' and Thunderbird's Update is absolutely painless, won't change any customizations and even checks for the compatibility of plugins). But this will take some time to do for CMSimple_XH, so we should concentrate on the update availability check first, as this is a prerequisite for the automatic update.