Relative URLs in blocks.

[tzyganu]

A lot of the blocks have methods that return relative URLs.
Let's take for example the advanced search block Magento\CatalogSearch\Block\Advanced\Form.
There is this method

public function getSearchPostUrl()
{
    return $this->getUrl('*/*/result');
}

This means that the submit url for the search form (that by the way is submited via GET and the method is called getSearchPostUrl ) is {current_module_key}/{current_controller}/result.
This means I cannot include this block in a custom cms page or block like this:

{{block type="Magento\CatalogSearch\Block\Advanced\Form" template="Magento_CatalogSearch::advanced/form.phtml"}}

Because I'm on a cms page the module key and controller won't match the advanced search ones.
I have to either create my own block that extends Magento\CatalogSearch\Block\Advanced\Form and changes the getSearchPostUrl and use that one, or I have to clone the template and change the form action.

The solutions I'm thinking of are:

1. Simple and fast: You can change the block method to return $this->getUrl('catalogsearch/advanced/result')
2. The flexible one, allow dynamic values for urls.

public function getSearchPostUrl()
{
    if ($url = $this->getData('search_post_url')) {
         return $this->getUrl($url);
    }
    return $this->getUrl('*/*/result');
}

This will allow developers to do something like this:

{{block type="Magento\CatalogSearch\Block\Advanced\Form" template="Magento_CatalogSearch::advanced/form.phtml" search_post_url="catalogsearch/advanced/result" }}

This may not be the only case, but it's the first I found.

[kandy]

Currently, the layout supports the generation of URL. see: admin grid url
I'm not sure this is what you need, but take a look

[tzyganu]

@kandy Thanks. I've already been through the new grid system.
First of all, not all grids support that (yet).
Second, I was referring to the frontend blocks. Maybe I should have made that more clear.
In my second solution I proposed something somehow similar. At least as a concept.

[kandy]

you can use this functionality anywhere. Define in layout

<block class="SomeBlockClass">
   <arguments>
         <argument name="result_url" xsi:type="url" path="*/*/result" />
    <arguments>
</block>

and refer to this in template getResultUrl() ?>

[tzyganu]

@kandy I know what I can do. I even explained in the issue. But that's exactly what I'm trying to avoid. In order to use <?php echo $this->getResultUrl() ?> I need to edit the template (or clone it). It shouldn't be like that.

[alankent]

So you are saying you believe getSearchPostUrl() has a bug - it should not use a relative path (*/*/result) because search is useful to drop in all over the site. So in this specific case it makes it more reuseable by using an absolute path. Have I understood your issue correctly? Thanks!

[buskamuza]

@tzyganu , are there use cases for solution 2?

I think that providing search URL is a responsibility of the module because only module knows how to process it. So I'd vote for solution 1. And if extended module wants to change the URL, it will override this method.

While with solution 2 the responsibility goes to front-end developers and it lets put anything (e.g., 'customer/account') that may not correspond name and intent of the method.

So for me it looks like a bug in the getSearchPostUrl() method - it should not need "any controller", it should need "certain controller".

Does it make sense?

[tzyganu]

@alankent. Not actually a bug. More of an inconvenience. Having the submit ur like */*/result limits the usage of the block to a single controller. I cannot use the advanced search form in the homepage for example without creating a new block or a new template

@buskamuza. I wrote the suggestions of the top of my head. I didn't think them through. I was just trying to come up with half of an idea. Maybe someone can turn it in valid code. But the bottom line is that the advanced search form submit url should not use * for module and controller. Most probably there are other blocks like this