Hi,
That was a very fast answer, Christoph, thanks.
cmb wrote:I agree that the decision between CMSimple_XH and CMSimple v4 currently comes down to some small details (if one doesn't need the subsite or co-author feature of the latter).
Funny. The first time I worked with CMS (by insistence of a partner), some years ago, those features would have been nice. People around me wanted to refresh their previous site, combining the easiness of CMSimple to managing content, with pages already done that accessed databases. I thought also they wanted the same look and feel of the old site. So, in the end, I created a site which was composed by several CMSimples working in parallel, along specialized pages difficult to put inside CMSimple... a virtual site which looked the same everywhere but internally was several CMSimples looking alike. So, I'm a buyer to CMSimple_XH 1.6 argument that it is doable to install different CMSimples to each subsite (if needed), because I already did that. It is not nice or easy, but if that prevents complications, I understand it.
Recently, I thought to upgrade that work to a more modern CMSimple, from version 3, and to join all the CMS into only one, even if that would sacrifice some look and feel of the original site. I started with CMSimple v4 because... 4 is after 3, right? Then I discovered there was something called CMSimple XH. Well, I tend to stick with my first choices, and CMSimple v4 works very fine. That should have be the end of it. But what I was finding of CMSimple_XH, the community, the resources, the road-map, the answers when I googled something about CMSimple, it was very alluring too. So, I decided to implement my site with both versions, see how far I could go with each. As I said before abut CMSimple_XH, "maybe it was luck, it was the first one I got to function with wraper, a plug-in I wanted to use"... that decided it.
Now, I started using the word funny, but I should have used the term "funny to the square" instead. Because, CMSimple is presented as CMS without need of a database, but the users of the site I was talking about, want to use it as a front-end to a site that is able to use databases. Either is (mine) ignorance or a tribute to the (effectiveness of) CMSimple, they like it, they want it. That's one of the reasons why my first CMSite was a collection of several ones, because some of the entries on my main menu were database generated. At the time, I didn't do anything better than to construct non-cmsimple pages to deal with that, accessed from the main menu which choose also which CMSimple installation to choose on the other entries. For unify all these in one single CMSimple, I'm now using a slightly changed li() function, called with toc(null,null,'li2') at the template - a nice surprise in the toc(), in relation to other CMSimple versions I tried before -, that when it finds an heading (H1, H2, H3...) with a special sintaxe, will feed it to a costumable function that will return the final menu to substitute the one that should have created with the Header. That's the reason why I wanted wraper, I wanted to avoid unnecessary calls to the database to create the menu, each time an entry was chosen... if the menu was created from the database.
I'm explaining all this (sorry if it is long), because, maybe you know more elegant ways to do that. Or if not, perhaps you find it enough interesting to discuss it to be included in the future, or even in the 1.6. The changes to do in the li() are minimal, about 3 lines. The call argument on the toc() allows me to do this without change the CMSimple core, so it is not really important, but I fail to see a good way to do a fallback if the right template is not used. In that case, the entries with the funny syntax would appear... and I cannot use a #CMSimple hide# because I'm under the impression that in that case, the toc() function will filter it before it reachs the li() function (and the hide() is hard-called into toc()... so, I cannot substitute hide() without substitute the toc... it starts to be to many core functions to substitute; I want to reduce my hacks to minimal, to get the most from CMSimple improvements.).
A similar concern I solved in the past with another hack, is to differentiate pages inside the cmsimple which are public, from ones which are only accessible through an intranet. Can you tell me if there is an elegant way (an add-on or a feature usable under 1.6) I can use?
cmb wrote:Indeed, there is a bug in the Pagemanager. This behavior was pointed out to me a few days ago, but I didn't had time to check out the exact reason. An ad-hoc workaround is to change the URL after calling "Pages": replace /?&normal&xhpages with /?&edit&xhpages and press enter. After this, the page structure should be okay, and you can use the Pagemanager as usual.
I tried that and it works. Thanks!
cmb wrote:
jpafonso wrote:Forgive me if this is not the right place (or even the right time) to report this.
This place is perfectly fine
But perhaps not for the kind of long talk I wrote earlier. Sorry. I'll compensate it later (Experimenting like I'm doing, I'm fated to find bugs if there are ones).
Thanks for the attention.
João Pedro Afonso