Custom Block template doesn't seem to be working

Permalink
Hi,

I just created a new custom block (a modified version of the Page List block). It's placed in the "/blocks/page_list_filtered" folder of a C5.4.2.2 installation on MAMP.

Inside that folder, I have a "templates" folder. I want to create a template that will have a view AND a .CSS file (for some custom styling). So... I created a new folder under the "templates" folder called "filtered_blog_index" and put a "view.php" and a "view.css" file in there.

So the whole thing looks like:

/blocks
   /page_list_filtered
        -add.php
        -auto.js
        -etc..
        /templates
            /filtered_blog_list
                -view.css
                -view.php


BUT... when I add the block to a page... and try to select the new (and only) custom template, it only shows the default "Blog Index" template from the original "Page List" block.


What have I done wrong? Why isn't MY custom template for my new custom block showing?

Thanks!
- John

arrestingdevelopment
View Replies: View Best Answer
s2d replied on at Permalink Reply
s2d
This might be a dumb question, but just want to confirm, is the block you're adding to the page your custom block, or the original one?
arrestingdevelopment replied on at Permalink Reply 1 Attachment
arrestingdevelopment
Kate,

No question is a dumb question... and starting at the simplest possible solution is always smart.

But... I just double-checked and I AM using the new, custom block on the page. But it's still displaying only the "Custom Template" from the original "Page List" block.

I've attached the "controller.php" file and "db.xml" files that I altered... in case they provide any insight.

Thanks!
- John
12345j replied on at Permalink Reply
12345j
maybe try renaming the block to filtered_pages_list? sorta weird problem.
arrestingdevelopment replied on at Permalink Reply
arrestingdevelopment
J-

Good idea. I just gave that a try... and no luck. When I add a new block to the page using the "filtered_page_list" block type, then try to select the "filtered_page_list" TEMPLATE, it doesn't show. The only template that's showing is the "Blog Index" template that comes in the default Page List Block!

UGGH! I must be missing something... like something in the Block Controller that's setting a path back to the default block? Or that needs to be changed for the pathing to this custom block?

Next? ;)
jordanlev replied on at Permalink Reply
jordanlev
That is very bizarre. In addition to 12345J's suggestion of renaming the block so it doesn't start with pagelist/PageList/page_list, also make sure you've cleared your C5 cache.

One more thing... I've noticed that sometimes C5 tries to pull view.css files from the block directory, even when using a custom template. So try moving your view.css file up one directory so it's next to the templates/ directory instead of inside it.
Of course this doesn't explain the weirdness around it pulling the view.css file from another block (unless you also have a page list block on the page somewhere else?).
arrestingdevelopment replied on at Permalink Reply
arrestingdevelopment
Jordan,

Tried clearing cache, but no change. I also tried moving the view.css up a level, but that's sort of a secondary issue at the moment... since the custom block isn't even letting me select the custom template that would need the custom view.css. :(

I also checked on your thought about there being another page list block... there was. The main nav. I tried removing that from the page, re-clearing the cache, and attempted to re-select the custom template. Still no go. AARRRRRGGGH!

Is there something special about the default Page List block that makes it resistant to being duped and edited?!?!

Thanks! Still trying!

- John
jordanlev replied on at Permalink Reply
jordanlev
If you copied the page_list block then it's possible you missed something that should have been renamed (block class name in the controller, for example).

Can you ZIP up your whole custom block and post it here?
arrestingdevelopment replied on at Permalink Reply 1 Attachment
arrestingdevelopment
Jordan,

After you suggestion, I went through the elements of the block to see if there was anything that I forgot... but I'm not totally sure what I'm looking for. ;)

Here's the block ZIPped up. It's gone through some permutations while I've been trying to figure this out... so it could be a bit botched up.

I appreciate you helping out!

- John
arrestingdevelopment replied on at Permalink Reply
arrestingdevelopment
P.S... I just KNOW it's going to be something dumb... so I'm smacking myself in the head now, just to get it over with. LOL!
arrestingdevelopment replied on at Permalink Reply 2 Attachments
arrestingdevelopment
OK. So I thought I'd try starting from scratch this morning, after having gotten a good night's sleep.

I started with a clean slate: fresh, local installation of Concrete5 v5.4.2.2 running on MAMP. Using the default theme and allowing the installation of the sample content. Then I copied the "Page List" block from out of /concrete/blocks/page_list and into the /blocks folder, renaming it to "filtered_page_list". I made the same changes to the controller that I had made before, changing the btTable, public Name and public Description and adding in the code to apply "Public Date" filtering (my ultimate goal).

Then I changed the "table name" attribute in the db.xml file to match what I had done in the controller.php file.

Then I changed the name on the "blog_index.php" template to be "filtered_blog_index.php".

Tried adding this new version of the block to a new page in my site. When I attempt to select the new Custom Template, it doesn't show. All I see is the "Blog Index" template from the default Page List block, not my newly-named template. ARRGGH!

Oh... and when I DO select the "Blog Index" custom template that shows, I get the following error:
Fatal error: Call to undefined method Controller::getCommentCountString() in /Users/bcbounders/Sites/blogtest/concrete/blocks/page_list/templates/blog_index on line 17


I've attached a ZIP file of my newly-created custom Page List block, along with a screenshot of the error when using this custom block and applying the "Blog Index" custom template that insists on showing as the only custom template.

Thoughts anyone? I'd love to figure out why this isn't working!

Thanks!
- John
arrestingdevelopment replied on at Permalink Reply
arrestingdevelopment
DOH! Scratch the issue of the error... it was because I hadn't selected pages of type "Blog Entry" for the block... so it was looking for Comments that didn't exist on standard pages. My bad. Guess that "good night's sleep" hasn't helped clear any brain fog! RATS!
arrestingdevelopment replied on at Permalink Reply
arrestingdevelopment
OK... one more tidbit of info before I hurl this computer out the window (time for a break, huh? LOL!):

Looking into the database through phpMyAdmin, I can see the "btFilteredPageList" table exists. BUT, after adding an instance of my "filtered_page_list" block to a page, there is no DATA in the table.

Does THAT mean something? I hope so! ;D
NBardales replied on at Permalink Reply
NBardales
I'm no expert in custom blocks, but that means there might be a problem with your db.xml file, which is the one that controls how everything gets stored on the database. I'll give it a try.

Oh and about the comment string, I normally just delete that line if I don't need it. And (in case you haven't already) enable debug mode to show all PHP errors, this will help you while you're still developing.
arrestingdevelopment replied on at Permalink Reply
arrestingdevelopment
Nicole,

Thanks for taking a look. Based on your thought, I just took a look at several different default blocks to compare them to my custom variant of the Page List block. I found something interesting, but it doesn't appear to have had an effect (I'm hoping you'll have better luck).

Here's what I found:

In the db.xml file of the default page_list block, line #13 reads:
<descr>Was enum, display_asc','display_desc','chrono_asc','chrono_desc','alpha_asc','alpha_desc','score_asc','score_desc'</descr>


I thought that code was missing an opening quote somewhere, so I looked into the db.xml file for the auto_nav block (figuring they'd be somewhat similar). Here, the equivalent code shows like this:
<descr>was enum('top','current','above','below','custom')</descr>

Note the opening parentheses and opening quote after the "enum"?

So... I changed the code in my customized page_list block (now called "filtered_page_list") to be like this:
<descr>was enum('display_asc','display_desc','chrono_asc','chrono_desc','alpha_asc','alpha_desc','score_asc','score_desc')</descr>

Then I went into the Dashboard / Add Functionality page, selected the custom block, and told it to "Refresh" (which I'm assuming has it re-read the core files for any structural changes?!?!).

No change. Still only shows the Custom Template from the default page_list block.

But... maybe I just found a glitch in the core code of v5.4.2.2? LOL!

Thanks... can't wait to hear if you've found something!

- John
jordanlev replied on at Permalink Best Answer Reply
jordanlev
Okay.... I did some digging here and saw that when you add your custom block to a page, it's actually adding a Page List block (so the problem isn't anything with your custom template but instead that your custom block is never getting added to the page -- as soon as you click on your custom block in the "Add Blocks" list, you're then dealing with the built-in PageList block only and not your code at all).

I stepped through a bunch of code and thought there was some nasty bug in C5... but after much investigation I realized it's caused by the following lines in your block controller's add() and edit() functions:
$this->set('bt', BlockType::getByHandle('page_list'));

What this does is swap out your custom block type with the built-in block type and sends THAT to C5's add/edit dialog. If you remove that line from both your add and edit functions, everything should work fine.

This is always the danger when you copy and paste code (or take existing code and modify just one portion of it). I also noticed some other things that will cause other problems, like you have SQL statements writing to btPageList instead of your custom block type table.

What you're going to need to do is use your text editor to search all files within your custom block directory (you'll have to learn this if you don't already know, it's different for every text editor), and find the following strings:
PageList
pagelist
Page List
page_list
btPageList

...etc. -- basically you need to find any and everything in your copied code that references the original pagelist block and change it to be your own. (But in the case of that offending line of code I identified above in your add and edit functions, just remove that entirely -- for the life of me I cannot understand why that would have been put into the pagelist block controller in the first place -- it makes no sense whatsoever, unless it's leftover from Concrete5 version 1.0 or something like that).

Overall, the code for the built-in blocks is *extremely* messy, so you really need to be super careful when copying them (I'd try to avoid it at all costs actually, but sometimes it has 99% of the functionality you need so I understand why it's necessary on occasion).

-Jordan
arrestingdevelopment replied on at Permalink Reply
arrestingdevelopment
Jordan,

Once again, it's Jordan to the rescue! Can't say "Thank You!" enough!

You're right... there's definitely danger in copying/re-using someone else's code (even if it is core Concrete5 code, apparently!), especially when you're not TOTALLY sure what you're doing, LOL!

When going through the code for the block, I wasn't sure which, if any, of those COULD be changed. I assumed that the "page_list" object was something I needed... so when it was being called in various places, I wasn't sure if the code was referencing the block called a page_list, or some more core object called a page_list! So I was afraid to muck around too much.

To that end... there's still two places in the controller.php code that I have a question about:

Line 28:
Loader::model('page_list');


Line 53:
$pl = new PageList();


If I change line 28 to 'filtered_page_list', I get a Fatal Error saying that "Class 'PageList' not found" on line 53.

If I also change line 53, to 'FilteredPageList', then I get the same error claiming that "Class 'FilteredPageList' not found" on line 53.

So... should I LEAVE those two? Are they referencing some core object called a Page List that is sacrosanct (and, more important, necessary)?! Or am I just not looking in the right spot to tidy things up, once again?

Thanks so much!

- John
jordanlev replied on at Permalink Reply
jordanlev
Oh shucks, it appears I was too hasty in saying to replace all instances of "page_list and PageList. Those ones you mentioned need to stay the way they are (because they're referring to the PageList API which is what actually performs the page queries in code, not the block itself -- confused yet?).
So yeah, leave those two the way they were :)
arrestingdevelopment replied on at Permalink Reply
arrestingdevelopment
LOL! I think I just had my epiphany and came to the same conclusion. I should THANK YOU for being "too hasty"... without that, I wouldn't have had my learning moment.

Thanks you, sensei. I feel like I am beginning to see the C5 path in front of me now. LOL!

- John
jordanlev replied on at Permalink Reply
jordanlev
Awesome, it was all worth it then (except for the days of frustration you probably had to deal with before figuring all this out) :-/
arrestingdevelopment replied on at Permalink Reply
arrestingdevelopment
LOL! No pain, no gain, right?!

As always, thanks for your help, Jordan!

Happily plugging along in C5,

- John
arrestingdevelopment replied on at Permalink Reply
arrestingdevelopment
Oh... wait. The loader is loading the MODEL page_list... from within /concrete/models, right?

So, I'm just getting confused by the fact that there is a BLOCK called a page_list (which I am duping and mildly modifying) AND there's an OBJECT called a PageList that is defined in the system by the MODEL called page_list.

Right?

So... since I don't need any (or don't THINK I need any) new functionality (per se), I can leave those references alone, right? The first on Line 28 is loading up the MODEL called a page_list. And then line 53 is using the class defined in that model to instantiate a new object.

Right?

I feel the dangerous feeling of an "Ah-HAH!" moment coming... and I KNOW I've only got a LITTLE bit of knowledge, so that's REALLY dangerous. LOL!

Thanks for the help!

- John