Idea involving a small change in content.htm

[svasti]

Hi developpers:

Plugins usually don't directly access the content.htm. Rather the content.htm is converted into a number of arrays and the plugins read from and sometimes write into these arrays. So the following change may not break existing plugins :

At present a new page is started by its healine in a fitting <h-...> paragraph. However, the pagedata follows right away, and the pagedata also indicates that a new page is going to be started. So the start of a new page is indicated twice... why not let the pagedata do the job alone?

i.e. a new page could start when the <?php $page_data[]=array(... is encountered and the pagedata could have 2 new key-value pairs, namely: 'headline' => '...' and 'level' => '...'

In admin editing mode the headline could be in a text-input line (styled according to the h-x of the template) e.g. below or above the online editor. Similar to the other pagedata tabs there could be a pagedata tap on the right side with the menu level written on it. Thus the headline would still always be visible, only on saving the ajax pagedata save would have to be done first.

Deleting the headline+save would glue the page to the preceding page. Breaking a page into two pages could be done by entering {{{headline 'my new headline,1'}}} inside the page contents.

Possible advantages:

• free use of all h-levels
• no more calls from users "help, my page is gone"
• one could add new levels without reworking the content
• no head scratching, how many levels do I need, in planning a site and before entering text
• the online editor drop down list for the paragraphs wouldn't have to be altered by "#1 level headline" for "h1".

[cmb]

Well, maybe we should indeed change the classic CMSimple way of managing the content. As I understand it, it causes a lot of confusion to new users, and probably there are not many old-style-users making good use of structure. If we do so, I'd like to go a step further, though, i.e.

Deleting the headline+save would glue the page to the preceding page. Breaking a page into two pages could be done by entering {{{headline 'my new headline,1'}}} inside the page contents.

Why not add buttons for this? Joining with the previous page would be trivial, but even splitting a page could be accomplished with a small editor plugin.

Anyhow, it seems to me that doing that in a feature branch has the advantage that we could present the idea ready for testing/evaluating by end-users.

[svasti]

Why not add buttons for this? Joining with the previous page would be trivial, but even splitting a page could be accomplished with a small editor plugin.

+1

Anyhow, it seems to me that doing that in a feature branch has the advantage that we could present the idea ready for testing/evaluating by end-users.

+1

[svasti]

Just got an email from a user who tried my suggestion to str_replace certain headline levels with other levels, in order to be better liked by google.
Anyhow he experienced some problems -- and the str_replace is really a kludge.
My above suggestion would make it superfluous,

that doing that in a feature branch has the advantage that we could present the idea ready for testing/evaluating by end-users

however I am afraid that I wouldn'd be able to write the necessary code myself

[cmb]

Anyhow he experienced some problems -- and the str_replace is really a kludge.

Maybe one of the alternatives posted in another thread would solve the problems.

i.e. a new page could start when the <?php $page_data[]=array(... is encountered and the pagedata could have 2 new key-value pairs, namely: 'headline' => '...' and 'level' => '...'

For the record: Holger posted a related suggestion a year ago.

that doing that in a feature branch has the advantage that we could present the idea ready for testing/evaluating by end-users

however I am afraid that I wouldn'd be able to write the necessary code myself

I may give it a try (can't promise that, though).

[svasti]

I may give it a try

Thinking about the future of XH: CMSimple was born in times of comparatively powerless computers and expensive tiny webspace (my first webspace had 5 MB, which was devided between 3 domains).
You get now fast 1 GB webspace + 1 Database (speicherzentrum.de) for 3 € per year, so the advantage of a small system is less obvious.
And there are about 100 times more plugins and themes for wordpress etc. as for XH. Therefore an evolutionary push for XH might be interesting.