Can't run action method for Page List block

Permalink
Hi There,

I am currently on version 8.4.3, and I'm having an issue getting action methods to work in a custom controller for a page list block. I have a controller at /application/blocks/page_list/controller.php with the following code:

<?php
namespace Application\Block\PageList;
use Concrete\Block\PageList\Controller as PageListBlockController;
class Controller extends PageListBlockController
{
    public function action_testplease()
    {
        $this->set('testVar', 'Set the variable');
        $this->view();
    }
}


I have tried navigating to the url that this page is on, so like example.com/path/to/page/testplease, but it doesn't execute the action. I have also tried generating a form with
$view->action('testplease');
as the action of the form, but no matter which way I do it, the action won't execute. If I do this same method with a content block, for example, both navigating to the URL manually and submitting a form with the correct action will run the method in the controller.

I should also mention that I have already checked the "Allow other blocks to filter this list" in the page list options.

I have looked at a couple posts that have mentioned this same issue, but it didn't seem to have any solution, so I wanted to revisit it to see if it was a bug, or if there's just something I'm missing.

Am I better off using a search block, and incorporating a page list that I filter through code, or is there a work-around for this?

View Replies:
A3020 replied on at Permalink Reply
A3020
Have you cleared the cache? Then first test if the class is picked up, e.g. by adding a view method in it with a simply 'die'.
dsw528 replied on at Permalink Reply
Yep, I've cleared the cache already, and just tested by adding die(); to the view method, and it worked, so the class is setup properly and working, just not any action_ methods.
A3020 replied on at Permalink Reply
A3020
Have you tried going through the code step by step, e.g. with Xdebug?
mnakalay replied on at Permalink Reply
mnakalay
I think the problem is from the method getPassThruActionAndParameters() in the block's controller. That method overrides the one from BlockController and is responsible for getting parameters to your action. If you look at it (and my understanding is correct) you will see that it looks for a parameter indicating filtering and if it can't find any, it nullifies not only the parameters but the method as well so it's never called.
dsw528 replied on at Permalink Reply
So is this a bug in the design, or intentional? If it's intentional, am I simply missing part of the steps to make the action_ method work, such as not passing something that I should be passing, or should I override the getPassThruActionAndParameters method in my custom controller, or something else entirely?
mnakalay replied on at Permalink Reply
mnakalay
Frankly I'd say it's a design mistake.

I think you can simply override it. Keep the code as it is, simply make sure that you don't nullify $method and it should work
JohntheFish replied on at Permalink Reply
JohntheFish
I would say a gap rather than a mistake. The Page List block does what its intended to do. It just isn't flexible enough to easily override for what @dsw528 wants it to do.
mnakalay replied on at Permalink Reply
mnakalay
You might be right, mistake is probably a bit strong. Having said so, the way the block is designed intentionally prevents us from using a very common C5 tool (actions) and I can't figure out why.
JohntheFish replied on at Permalink Reply
JohntheFish
I suspect @dsw528 is correct in that all the url segment info that would normally go to an action is now being grabbed by the pass through handler. So overriding that to detect an action and dispatch to the action method, or pass on to the parent method, would be where to look for a solution.

The pass through handler must already do some url/dispatching behaviour because it can take parameters from external filtering blocks as well as its own pagination.

Personally, rather than override the core Page List block controller, I would create a new block type and extend the core block. That way I wouldn't have to worry about maintaining existing behaviour for other uses of the core block and side effects from failing to do that. I would only need to worry about what I needed for the new block.
dsw528 replied on at Permalink Reply
That sounds better. If it's risky to override the controller in this case for the page list controller, I'll probably go with a new block type.

I also saw someone else in a different post recommending creating a custom template for the Search block that implements a Page List through code, which could work since all I'm really wanting to do is create a page list that allows the front end user to filter by different attributes (including custom page attributes) that we put into a form on the page, and it would include searching the list by a text field as well, so I may go with this option in the end, depending on what I find out.

Either way it seems like my next step from here is to not pursue this with the page list block.