New Custom pages ignored by dev/build

Silverstripe Version:
SS V 3
I have made new Page files (extends Page and Page_controller) but they don’t get visited and used by dev/build.

Details of your query go here
My site is some years old and has a few dozen descendants of Page, absolutely normal SS stuff.
After some months of no development, I now want to make a new page, quite vanilla, nothing at all fancy. But dev/build recognises no new pages.
I even cloned a working one, named it. Nope.
Here is 100% of my CurtainTypeMainPage.php

 * Class CurtainTypeMain Page
class CurtainTypeMainPage extends Page

 * Class CurtainTypeMainPage_Controller
class CurtainTypeMainPage_Controller extends Page_Controller
   public function getTitle() {
      return 'curtains';

Easy as pie, eh?

Trying to provoke any response, I put a bit of random junk in the php, but dev/build did not notice. I put the same junk in an existing Php Page class in same folder, and got the expected PHP syntax error.

(Windows file extensions are “on” so I know this is not secretly a .txt file masquerading as PHP). SS behaves as if this new page file does not exist.

I have tried three differently named pages. I have tried ?flush=1.

I am befuddled, as you might expect. I expect it is a bonehead mistake. Thank you in advance.

Works for me on version 3.1.13

Make sure CurtainTypeMainPage.php is inside the /mysite/code/ folder then do a dev/build.
Check out Lesson 04 to learn more

Thank you Isaac. In my case it is in a subfolder, mysite\code\PageTypes. This has been there for years and the subfolder has 15 other similar files, which have all worked in the past.
Now, somehow, the new ones are not recognised.

A new Sherlock is needded for this. I discover that I am in even more of an X-Files alternate reality…

I took the UncleCheese simple lesson 4 “Home” Page and changed its name:

class DavetestPage extends Page {


class DavetestPage_Controller extends Page_Controller {


How simple can it be?
And I uploaded this to a completely different site from the one I posted about above. Both my local dev version and the live one. Both SS2 not SS3 but that should not matter.

I did dev/build and no new pages were created on either site. There was no sign of Davetest Page in the CMS. Just the usual list of tables and records appropriate for that site (and of course not the files for site 1).

It did not silently create the new Page Type. If I try to create a new page, I only get the expected types and not the new one.

Then I got desperate. Suppose my ss is not using the database that I expected? Maybe my “live” config.php was accidentally using my local db? So on my local machine I turned off SQL; and as expected, dev/build on local failed, dev/build on Live worked (but did not notice Davetest page)

Maybe my live config.php has been hacked and is pointing to some villains database? So I used my (commercial, non local) host control panel PhpMyAdmin. I renamed the table ContactPage to ContactPage_test. I did dev/build and (yippee) : SS did build me a new Contact page table. I deleted the new empty one and renamed ContactPage_test back again, did dev/build, and nothing happened, all is back to normal. I hand edited content of a page via PMA, and this was displayed when I refreshed the website.

I edited the config file that I see in FileZilla by changing the SQL host name, and then the site stopped working. I put it back to normal.

All of which nitpicking pretty much proves that my live SS site really is using my live SS db.

It is as if my new files are invisible. It makes no sense, does it? I must be doing something utterly stupid, I hope so. I asked Fox Mulder but, despite his other talents, he’s not a dab hand at Silverstripe.

Your code works for me on SilverStripe 2.4.13. Are you able to create new pages or edit existing content within the CMS?

Hi Isaac. Thank you for taking the time to check. Yes to both your questions.
And in fact this works both on my main clients site (SS3) and my own work site (SS2).

I wondered if I am uploading to an unexpectedly hidden folder. So (on the SS3 site) I edited an existing somethingPage.php (which is old and works fine) by inserting “&&89 4-” deliberate rubbish. I refreshed the live web page which uses somethingPage.php and as expected the page fails, all white. I tidied up the PHP rubbish, refreshed the page, and the page worked.
This is in the same folder that I have put my CurtainTypeMainTest.

In further desperation I wondered if something failed in parsing files alphabetically after the letter “B” (which I have many of). So I renamed my test to start with “A”. It is still ignored.

Your CurtainTypeMainPage doesn’t have a $db declaration, which means you wouldn’t get a table for it in the database, but that doesn’t seem to explain all of the problems you’re experiencing. Still, maybe try adding a few database fields to your class and see if that triggers a change?

Hi guys. I have solved it.
You can stand in the queue to kick me after I have finished kicking myself.

The php file I was uploading was somehow in “UTF-DOS” code page, presumably 16 bit not 8 bit Ascii. I don’t know how. But presumably SS could not make any sense of it even though it looked normal in my editor, and presumably did not recognise it as PHP. So didn’t process anything in it.

Once I converted it to regular DOS code page, everything behaved.

This must be a rare mistake but not impossible to happen to other people. And it could be any component of the CMS, not specifically the Page class.

So thank you Isaac and Jono for your replies and taking the time to read about this bizarre event. Happily it has a solution, unlike some others.

1 Like