Problem with page_params.php ?

[Gert]

Environment: CMSimpleXH ver. 1.4. There is no update of page_params.php in this version so it must be one from the earlier update.

It's not necessary.

New installation: If the content folder is writeable, CMSimple_XH creates a pagedata.php.

Update: If you update your installation, make a backup of content.htm AND pagedata.php and insert them (after the update) to your updated installation.

[jerry]

I managed again to destroy the synchronization between page_param and content.htm. The error occurs when I rename a heading of the page, save the page and then insert something in the "Alternate heading" under the Page tab of the same page and save it. After this the page_param file is ouf of syncronization with content.htm.
jerry

[Gert]

Hi Jerry,

witch CMSimple_XH Version was in use? CMSimple_XH 1.4?

[jerry]

Hi Gert
It was a clean installation of CMSimple_XH 1.4 utf-8, language English, without any changes in core code, expect of added scheduling of publishing period in page_param.

By the way, it was decided that scheduling should be af part of core CMSimple_XH distribution package. Does anybody know when this will happen?
jerry

[Gert]

Hi Jerry,

I cant reproduce it in 1.4, but following happens:

1. If I save a page, the page is active in the menu and in the content, but not in the adress line anymore. In the adress line of the browser is the blank domain (+ install folder, if exists). That's a behavior of CMSimple, independent of pagedata.

2. If I change the page heading and save the page, the same happens.

3. If I change anything with meta_tags exactly in this situation and save it, the page is called under the OLD name (look at the adress line), below the edit menu is written: "Could not locate heading" - of course, the old page name doesn't exist anymore.

4. But nothing else happens, nothing is saved, no moved pagedata.

That are my test results.

Martin is doing some code cleaning and bugfixing of the core files, for a new version. He knows that. Contact him per PM, also for the scheduled publishing. But I think he will read this post.

By the way: scheduled Publishing is possible by RealBlog_XH plugin.

[jerry]

Hi Gert
It's exactly what happens, and it's a the way CMSimple unfortunetly works.

CMSimple Classic doesn't need to synchronize between content and plugins so it's not an issue, but with introduction of page_param, meta_tags, and hi_pd scripting it is a bug that potentially can destroy a whole site.

Until it's solved the workaround is to never make changes to these plugins without previous reload of the page.

I use scheduling in NewsRotator and as repalcement of ExpiredPage plugin, så I can't use RealBlog to do the job.

I'm sure that Martin read this post.
jerry

[Martin]

Hi Jerry,

the only thing I was able to reproduce, was just what Gert described: a momentary loss of synchronization just on on the screen, with no influence on the stored data. So did this

After this the page_param file is ouf of syncronization with content.htm.

really happen?

But anyway: The problem is that after saving a page CMSimple refreshes the content (in admin.php - rfc()), but this happens after all the plugins have been loaded. So they just don't know about the changes. I think this should fix the problem: Instead of re-reading the content in this stage, CMSimple should completely restart with the new url. So I tried this code as a replacement for the rfc in the ($adm && $f == 'save') { ...} clause in adm.php (~ l. 328):

Code: Select all

/* check for the first heading */
preg_match('~<h[1-' . $cf['menu']['levels'] .'][^>]*>(.+)</h[1-' . $cf['menu']['levels'] .']>~iu', $text, $matches);
if(count($matches) > 0) { /* If there is one: construct the new $su from it */
    $temp = explode($cf['uri']['seperator'], $selected);
    array_splice($temp, -1, 1, uenc(trim(strip_tags($matches[1]))));
    $su = implode($cf['uri']['seperator'], $temp);
} else { /* If there is no heading, the page has been deleted: set $su to the previous page */
      $su = $s > 0 ? $u[$s -1] : $u[0];
}
/* and now call the new $su */
 header("Location: " . $sn . '?' . $su); 

I am curious if that really solves the problem. So, feedback and tests with the attempt to destroy the synchronization, are very welcome.

And about your scheduling addition to page_params: I just reread the old discussion. Is your download link still up-to-date?

Update: Changed the previously hard-coded "3" to "$cf['menu']['levels']".

KR
Martin

[Gert]

Hallo Martin,

seems to work, have made some tests.

By testing I have found a similar behavior by login:

If I go to a page, and login from that page, the page is active in the menu and in the content, but not in the adress line.

That's not such a problem, because: if I save the page or change pagedata and save, the page is called, also in the adress line. With the old adm.php and also with the new adm.php (with your new code for rfc()).

But I think it were more correct, if the page (from where I have logged in) also were active in the adress line (like in the menu and in the content) after login.

[Martin]

If I go to a page, and login from that page, the page is active in the menu and in the content, but not in the adress line.

For that we just have to add the "$su" to the login-forms "action". (In login.php.)

KR
Martin

[Gert]

For that we just have to add the "$su" to the login-forms "action". (In login.php.)

I hope, you will do that in the "cleaned code" for the next release