Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

General Questions

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Weird Bug


7 Posts   1356 Views


2 April 2011 at 2:38pm Community Member, 56 Posts

So weird I wouldn't know what to call it.

In the CMS, press 'Save and Publish' page with ID 100

Pages with IDs 107, 21, 22, 23, 19, 20, 96, 13, 14, 1 also saved, but not published. Different DataObject Types, and no pattern I can see, it just publishes these same 10 pages with it. It also seems to be reverting them back to a previous version.

I discovered the other day as for a while one page has been reverting back to a previous version for no apparent reason.

I've just had another go, saving ID =1 (Home Page) also saves ID = 4(Error Page).

It's consistent too. I dumped the database on a dev machine, saved page 100 and all the same pages saved.

I was running 2.3.3 when I discovered, upgraded to 2.3.11 today, but still does the same thing.

Is there an option at all that will cause the CMS to save other pages when you publish?


2 April 2011 at 3:02pm Community Member, 56 Posts

and here's a trace if I put a user_error into the 'onBeforeWrite' method one of the page types that are getting saved automatically

<ul>user_error(do trace,256)
line 524 of MembersPage.php

line 783 of DataObject.php

line 1022 of SiteTree.php

line 783 of DataObject.php

line 397 of Versioned.php


line 550 of Object.php

line 1462 of SiteTree.php

line 1462 of SiteTree.php

line 688 of LeftAndMain.php

line 276 of Form.php

line 135 of RequestHandler.php

line 149 of RequestHandler.php

line 119 of Controller.php

line 280 of Director.php

line 121 of Director.php

line 118 of main.php

So the SeminarGroupPage is the one I'm saving and publishing, the MemberPage is the type getting saved and not published


2 April 2011 at 3:52pm Community Member, 56 Posts

So even more investigations, down to this piece of code (SiteTree.php lines 1014 to 1026)

// If the URLSegment has been changed, rewrite links
      if(isset($this->changed['URLSegment']) && $this->changed['URLSegment']) {
         if($this->hasMethod('BackLinkTracking')) {
            $links = $this->BackLinkTracking();
            if($links) {
               foreach($links as $link) {
                  $link->rewriteLink($this->original['URLSegment'] . '/',
                                              $this->URLSegment . '/');

I then went and emptied the table SiteTree_LinkTracking.

I saved page 100, 1 link tracking record created and none of the other pages saved.

Saved page 13, created a record in SiteTree_LinkTracking to 100 so that's how it's happening I guess. And now when I save 100, 13 and 100 are both saved.

So next question is, how can I stop this i.e. only save a page when I click save on that page? Or is the only way to add a return before the code above?


2 April 2011 at 9:54pm Forum Moderator, 1091 Posts

On saving a page while changing the Metatitle, SilverStripe will also update all links to this page that occur on other pages. That's what the SiteTree_LinkTracking table is for: keeping track of pages that have links to other pages. In order to update a link, the whole page needs to be resaved and/or republished. Could this be the case for your pages?

As for reverting back - I haven't a clue. Version 2.3 is getting to be a bit ancient, and I no longer use it. I suppose upgrading to 2.4.5 is not an option?


3 April 2011 at 1:32pm (Last edited: 3 April 2011 1:35pm), Community Member, 56 Posts

Thanks. I traced the versioning reverting, and that was actually something I'd done wrong, I'd adding something into the MembersPage type that when saved from the CMS properly, updated an external table, it broke it the page was saved another way without being loaded in the CMS.

I've considered upgrading, but I have built a pretty big module(CRM, Maillist handling) based on LeftAndMain, I started it on a Beta of 2.3 so it's got a lot of hacks and fixes to get around issues I had found along the way - Upgrading to 2.3.3 was a huge task for the module, 2.3.11 was pretty straight forward(although had to add the security password hack still so people could log in), I'm a bit worried that 2.4 will break everything again and require me to spend ages fixing. But, I think I'll do it this afternoon anyway(I've talked myself into it just posting this), I have everything versioned so if it doesn't work, I'll revert it back immediately, and I'm upgrading quite a bit on the site at the moment anyway, so it's probably the best time to take the plunge


3 April 2011 at 2:38pm (Last edited: 3 April 2011 2:40pm), Community Member, 56 Posts

Yeah nah, I attempted and I have hundreds of queries written with double quotes on the field value, will take a year to covert them all to single quotes, and they have to be double quoted in 2.4.x due to the USE_ANSI changes, I've even used CalendarDateFields throughout that seem to be gone now too - looks like I'll stick to 2.3.11 for now and change queries as I spot them and attempt another upgrade later


3 April 2011 at 8:01pm Forum Moderator, 1091 Posts

Tzja... Sorry to hear that. Sometimes things just...