[CLOSED] Pagemanager_XH 0.3 - 0.9

[cmb]

Hello community,

the original Pagemanager_XH thread was taken over with technical discussions, so I decided to open a new one.

I hereby announce the release of Pagemanager_XH 0.3.

Pagemanager_XH simplifies the administration of pages of a CMSimple installation. For more details and download visit http://www.cmsimplewiki.com/doku.php/pl ... manager_xh

I've updated the plugin to use jQuery4CMSimple instead of bringing it's own jQuery library with it. It should now work with other CMSimple extensions using the new jQuery4CMSimple plugin. It might still fail, when another extension should involve it's own jQuery library. But that was the point in developing jQuery4CMSimple: to have only one jQuery version for all extensions. It should also work with extensions using other JS frameworks that use $ (e.g. prototype.js).

Please try it, test it and give me feedback. But be warned: it is still ALPHA. In the worst case it could purge your whole content.htm and pagedata.php! So please, make a backup before trying it.

I'd really appreciate to bring out a Pagemanager_XH 1.0 ASAP. This should be a stable and comprehensively tested version with no additional features. IMHO it would be a valuable addition to the existing CMSimple_XH plugins, especially for end-users. To do this I need your help as testers. Translators are welcome too, but I guess it's better to wait for a more stable release.

Technical details:

Until there is agreement between the extension authors using jQuery on any convention to use the framework with regard to jQuery.noConflict(), I chose the following way:

Code: Select all

var pagemanagerJQuery = jQuery.noConflict();
...

As the used jsTree library provides no way to be used with jQuery.noConflict(), I wrapped it's call in a sort of renaming lambda (thanks to Martin, who gave this valuable hint). Maybe this could be of interest to other extension writers.

Code: Select all

(function ($) {
    // your old code using $ goes here
})(jQuery)

I really do hope that all extension writers who use jQuery, will update their extensions to use jQuery4CMSimple ASAP, so we all will have less collisions with other extensions.

Christoph

[cmb]

Hello community,

the first bug in Pagemanager_XH 0.3 is found!

The Problem: when you move whole subtrees into another one, and the resulting nesting level is deeper than your configured menu_levels (default: 3), all those pages will loose their state as separate pages, and be appended to the previous page (as if you've changed their heading accordingly, e.g. to H4). And so they loose their meta data. On it's own, it could be thought of as a feature , but it's worse:

The meta data of the following pages will be totally mixed up.

So consider this version as ALPHA, as you've been told, and do not use it for your real website. Use it only for testing. And make backups.

I'll work on a fix for the next version, and announce further information here in the forum.

Sorry for any caused inconveniences,
Christoph

[cmb]

Hello community,

while working on the fix for the mentioned bug, I found an interesting phenomenon:

With CMSimple (at least with CMSimple_XH 1.4; I did not test other versions), it is possible to have "irregular" page structures. I mean you can have a <h3> title as direct children of an <h1> title (without an <h2> title in between)!

Well, it's possible to have this, but I couldn't find one good reason to build a site this way. I guess with many templates the menu would look strange. Perhaps someone is using this feature to have a special effect with a template, but then IMHO it's better to adjust the template. Do I overlook some reasonable use of this feature?

The Problem: with a treeview, as used by Pagemanager_XH it is not possible to display such irregularities. It would be possible to adjust for the problem, but as I see it now, it could be better, if Pagemanager_XH will correct these irregularities on saving.

Any opinions appreciated.

Thanks,
Christoph

[Gert]

... but as I see it now, it could be better, if Pagemanager_XH will correct these irregularities on saving.

I don't think.

Some webmasters use that behavior to hide h3-pages automatically:

Code: Select all

<?php echo echo toc(1,2); ?>

So "h2 or h3" is not a question of site structure, but a question of visibility.

[cmb]

Hello Gert,

thanks for this enlightement. Indeed a good reason not to clean up the site's structure. I've already finished a version, that does it, but now I have to see, how it can be done with keeping the old structure. If possible, I'll release a version with a config switch (keep structure by default).

Thanks,
Christoph

[Gert]

If possible, I'll release a version with a config switch (keep structure by default)

That's the best (and should be easy to realize, if you have both variants ready.)

[Martin]

Hi Gert,

when Christoph pointed to the h1->h3-problem, I thought, we should change XH's saving procedure to ensure a clean html-hierarchy. But ...

Some webmasters use that behavior to hide h3-pages automatically ...

Hmm. Do you really think so? Well, I don't. At least webmasters should know a better way to hide a second level page from the menu than formatting it as h3 - one of the advantages of CMSimple_xh over the classic CMSimple is that this can be done with a mouseclick!

So I thought, that h1->h3 happens in the context of XH only by accident. Curious: Is there anybody out there who uses it on purpose?

Martin

[cmb]

Hello Martin,

At least webmasters should know a better way to hide a second level page from the menu

But consider a website that was started with CMSimple classic, and used this technique. The Webmaster told the user how to hide pages. Later the website was upgraded to _SE. The webmaster told the user: use menumager now. It's very easy and intuitive to switch the hidden state of pages. Simple solution: both webmaster and user are happy.

OTOH I think you're right. Now that there are "better" ways to do that nobody should use it. But if you put the cleanup to the core (without config option with conservative default), those metioned users can't update or must change their used way of working (and the template). And they must know that this change is required!

Curious: Is there anybody out there who uses it on purpose?

Me too!

Christoph

[Gert]

Some webmasters use that behavior to hide h3-pages automatically ...

Hmm. Do you really think so? Well, I don't.

Not my idea, I have found such things on customers websites ...

To make it configurable and set default to "no change site structure" is the best way IMO.

[jerry]

Hi Christoph
The new version works on my site thx jQuery4CMSimple. I will make some testing during the week.
jerry