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.

Customising the CMS /

Publish buttons dissapear just in one branch - and JS error


Reply


4 Posts   487 Views

Avatar
KINKCreative

Community Member, 56 Posts

30 September 2011 at 7:04pm

Edited: 30/09/2011 7:05pm

Hi guys. I created a new pagetype... Nothing too complex, the class is below...

I got called by a client today and a set of these VideoPages in a branch in the sitetree, about 3rd level down from the root, is not showing any Publish buttons. The VideoPages on any other section of the sitetree show the Publish button, but the button doesn't appear on any of these pages, all of them under a holder.

When the client then pressed "Delete from Draft site" - the Save and Publish started to throw the "getAllFields() on a non-object"... error. No clue where that may be coming from?

Any help on this would be greatly appreciated!!

<?php

class VideoPage extends Page {

    static $db = array(
      "YouTube" => "Varchar(255)"
    );

   static $has_one = array(
      "VideoThumbnail"=>"Image" //not used yet, I am therefore not adding the field
   );
   
   static $has_many = array(
   );
   
   static $defaults = array(
      "ProvideComments" => true
   );
   
   static $allowed_children = array();
   static $default_child = "";
   static $can_be_root = false;
   
   public function getCMSFields()
   {
      $f = parent::getCMSFields();
      $f->addFieldToTab("Root.Video", new TextField("YouTube","Enter YouTube link or video ID"));
      return $f;
   }
   
   public function LargeThumbnail() {
      if(!empty($this->YouTube)) {
         return "http://img.youtube.com/vi/$this->YouTube/0.jpg";
      }
   }
   
   public function IsNew() {
      $date1 = SS_Datetime::now()->Format('U');
      $date2 = strtotime($this->Created." +5 days");
      return $date2>$date1;
   }
   
   function canCreate($Member = null) {
    return true;
   }
   
   function canDelete($Member = null) {
    return true;
   }
   
   function canEdit($Member = null) {
    return true;
   }
   
   function canPublish($Member = null) {
    return true;
   }
   
   function onBeforeWrite() {
    if (preg_match('%(?:youtube\.com/(?:[^/]+/.+/|(?:v|e(?:mbed)?)/|.*[?&]v=)|youtu\.be/)([^"&?/ ]{11})%i', $this->YouTube, $match)) {
    $video_id = $match[1];
    $this->YouTube = $video_id;
    }
    parent::onBeforeWrite();
   }
   
}

class VideoPage_Controller extends Page_Controller {
      
   public function init() {
      parent::init();
   }
   
}

Avatar
martimiz

Forum Moderator, 1132 Posts

5 October 2011 at 12:44am

So you might think the reason llies with the location in the sitetree... Just wondering: if you drag one of these (newly created) offending pages to a location on the sitetree where videopages live that behave properly, will the button now appear?

Avatar
KINKCreative

Community Member, 56 Posts

5 October 2011 at 5:33am

Edited: 05/10/2011 5:33am

The thing is I can't even drag and drop them. I did it, the sitetree visibly changed, but refreshing showed the old structure. A few of them had wrong titles and I couldn't save and publish them (as stated above). So I was able to pull a Batch action on them to remove them from the draft tree (the delete from draft button, though there, returned an error too), and had to add a new page with correct info and save that one.

I wonder if there are any bugs when you are duplicating pages or pages with children, like something specific (class name?) is lost when you're duplicating... Something is pulling an empty site object and the fields are supposedly not there, that's what it seems to me. But I'm way too much in the dark here :)

Avatar
martimiz

Forum Moderator, 1132 Posts

5 October 2011 at 8:03am

I know of no bug in duplicating pages, have used it often - but of course that doesn't mean there isn't one.

Weird that the batch delete worked where the delete button didn't... Anyway now they're all gone - and obviously you can create new one's on the same location, so that's fixed :-)

I'm curious if this will reproduce when the client starts to work on them again. In that case maybe you should create a databasedump first before removing - maybe something strange happened to the records that will set you on track...