all page headings as <h1>?

[cmb]

Hello Frank,

I guess you're right, but I see two problems:
- it might not be clear what headings the user should use for best SEO. Say, he uses <h1> to format the sub-headings on the page, but the page is menu-level 3. This would result in a semantic error.
- there are several plugins out there that use their own rfc() (I'm at least aware of Pagemanager and Multilang, but I guess there are more). Changing the syntax of the headings in content.htm will break them.

Setting the level of the page could be done in the page-params

IMO that's not the right place for making changes to anything else than pagedata.php. But as Gert already wrote it is possible to store the menu level in pagedata, so this would be the right place to change this setting. But then again

But that were a new CMS

no more clients calling at night, help, help, where is my page?

You should tell them: "I'm quite sure that the page is gone to bed! And so should you!"

I would suggest: the user shouldn't be allowed to change the heading's menu level from the editor, but has to use a page manager, such as Menumanager or Pagemanager. That would furthermore help with inadvertently created irregular page structures.

Christoph

[cmb]

Hello Gert,

The basic idea of CMSimple was, not to need a page administration

I'm still wondering if Peter Harteg's first versions of CMSimple (perhaps the perl version) even had an online editor, so that the admin had to use an offline HTML editor to edit his content. Could anybody please shed some light on this?

Christoph

[svasti]

@Christoph,

it might not be clear what headings the user should use for best SEO

could be user defined, i.e. menulevel1 –> <h1>, menulevel2 –> <h2> etc, There could be a list which the user could change if he wants to.

IMO that's not the right place for making changes to anything else than pagedata.php

yeah, that's actually what I meant.

Changing the syntax of the headings in content.htm will break them.

I would also like compatibility to be kept. May-be a trick could do? We only have to differentiate pagesplitting headings from normal semantic headings. In the content.htm pagesplitting headings could be stored as before while all normal headings could be marked by a class (the editor has of course to be set up in such a way as not to show the class, and at the same time it should add this class to every heading).

I would suggest: the user shouldn't be allowed to change the heading's menu level from the editor,

That's why I did some changes to FCKeditor for my clients. My version of FCKeditor first shows all the semantic headings in wysiwyg-style. Only than the pagesplitting headings come. And their text is not "heading", but "new page #1", "new page #2", "new page #3". (I proposed this change for the next version, … but too late, as FCKeditor is on it way out.)

svasti

[cmb]

Hello Frank,

I would also like compatibility to be kept. May-be a trick could do? We only have to differentiate pagesplitting headings from normal semantic headings. In the content.htm pagesplitting headings could be stored as before while all normal headings could be marked by a class (the editor has of course to be set up in such a way as not to show the class, and at the same time it should add this class to every heading).

The problem is that splitting content.htm into pages is basically done by those plugins (according to rfc()) by:

Code: Select all

    $stop = $cf['menu']['levels'];
    $split_token = '#@CMSIMPLE_SPLIT@#';
    $content = preg_split('~</body>~i', $content);
    $content = preg_replace('~<h[1-' . $stop . ']~i', $split_token . '$0', $content[0]);
    $content = explode($split_token, $content);
 

so any attribute of the heading will be ignored

That's why I did some changes to FCKeditor for my clients. My version of FCKeditor first shows all the semantic headings in wysiwyg-style. Only than the pagesplitting headings come. And their text is not "heading", but "new page #1", "new page #2", "new page #3". (I proposed this change for the next version, … but too late, as FCKeditor is on it way out.)

But the idea should be integrated to the new editor(s), if it will be possible to change the headings of the page titles from the editor(s).

Christoph

[cmb]

Hello community,

I received a german PM with opinions regarding this topic. So I want to translate it.

a. IMO the data structure of a web application should not become dependent on the algorithm of search engines for ranking, especially when a system would need to be rewritten for it (in the complete handling of their data structures)
b. I've nothing against massive changes and improvements, e.g. when jumping to a new version number, if the changes of data structures would "pay off" -- for the user also , -}
c. with its structure and type of menu generation CMSimple is actually quite good, even for end users; they have just to sit down for 5 minutes and have to try to understand. Changing it to something substantially different, will mean a different CMS, which is partly done through the pagedata extension already ... but it's ok. Migration from a different / older CMSimple to a current _XH poses more problems with the conversion to UTF-8 as there were problems with the data page.

I see now with laughing and wondering eyes, that you try to adjust old barriers (only three menu levels, coupled with the <h1> - <H3> formatting) to -- well, to what actually? , -}

If you do something new, then please without any contamination and ballast, then switch to a database-oriented data structure, since it requires no "from behind through the chest into the eye shot" contortions in order to solve certain problems (ok, but maybe some new problems )
From a purely historical perspective, it has even made sense, as CMSimple urged the market to avoid a database connection; the neccessary web packages were significantly more expensive than "html only" (it is less than 10 years ago, I paid 10 € for a mysql database hosting). Free hosting with mysql wasn't available at this time at all, and database-based competitors were still more crappy in the handling for the end user (as I think back to CMS Made Simple awfullly, thanks to the amalgamation with Smarty that is anything but simple for end users ...).

But today? Mysql doesn't cost anything more, or is negligible in terms of cost. Even with free hosting you get more this year than one database for your account ....

So, either leave the structure of CMSimple intact, even though it is perhaps suboptimal for SEO, and some programmers might find the creation of the menu structure is inelegant ... or make a real cut and switch to a database-oriented design, with a standardized interface for plugins and templates -- for templates the level of Wordpress is sufficient (css and template files for the various possibilities of the page views), something like Smarty is IMHO "grenzdebil" a unnecessary abstraction layer, that takes away the fun for the end user, who does not want to fiddle with it.

Basically I agree with snafu. If incompatible changes were made to CMSimple, that should be done as a new major version (e.g. 2.0). And if that would happen, it has to be considered well, which changes should be made. But as this IMO wanders to far OT, it should be discussed in a different thread.

But my suggestion to change the output heading of page titles, which might not be the best idea, could be implemented IMO without changing the data structure of CMSimple, and without being incompatible to earlier versions or existing plugins. I'll best explain it with a sketch:

Code: Select all

<h1>Page1</h1>                 <h1>Page2</h1>
  <h2>Page2</h2>               <p>Lorem ipsum ...</p>
<h1>Page3</h1>

But Gert already explained, that it is not clear if this would improve search engine results. So we should leave it as it is for now.

Christoph

[svasti]

Hi everybody:

There seems to me a solution, which could even be implemented in the present version without changing too much code:

It is a bit like running CMSimple with 6 menulevels. There are no headings left. You have to use the style-menu to produce some <p class="pseudo-heading">.

The principle is:
In the Editor: <h1-6> are used as normal headings.
To create new pages in the Editor, you use the style menu to format a text line as <h1-6 class="pagespitter"> (could have some fancy css).
During saving to content.htm there will be a transformation
<h1-6> will become <p class="h1-6">
and <h1-6 class="pagesplitter"> will become <h1-6>

So the content.htm will be completely normal as before and compatible to plugin actions. It will just look like a content.htm of CMSimple with 6 menulevels.
The only difference would be some little preg-replace code line doing some transformations here and there.
For instande, when pages are called from the internet, they will be split according to <h1-6> in CMSImple fashion, but additionally the <p class="h1-6"> could be transformed to <h1-h6>. All this transformations could be user definable. The user could define that every page splitting h1-6 will be shown as <h1>.

What do you think?
svasti

[cmb]

Hello Frank,

well, I guess this is possible. I would suggest, that <hX class="page-splitter"> will only be available to menu_levels (not 6 in every case).

But IMO it would be even better, to forbid changing the menu level from within the editor (perhaps as config option for the convinience of power users). Setting the menu level of a page as it's done by CMSimple is somewhat ingenious, but hard to understand for end-users. And by using Menumanager or Pagemanager it won't be necessary anymore.

Christoph

[svasti]

Hi Christoph,

well, I guess this is possible. … And by using Menumanager or Pagemanager it won't be necessary anymore.

True, with your menumanager we wouldn't need a way to set pagesplitting headings in the editor.

CMSimple is somewhat ingenious, but hard to understand for end-users.

Therefore I always include Pagemanager with a direkt link to Pagemanager next to the Plugin-select box. There is unused space there. And Pagemanager is so important, that a direkt link is practical.
Why not use that unused space? One could also put a direkt link to your menumanager function. The user expects a pagemanaging function somewhere. This function is more important than validating links...
svasti

[cmb]

Hello Frank,

AFAIK for 1.5 it's planned to substitute the "image" and "download" links with links to a file manager and a page manager, already included in the base package. This version will provide hooks, so that plugins with according functionality could be called by this links, if they are installed, similar as it's currently done by hi_kc_finder.

Christoph