Symphony.

Only a minor issue, but I've not noticed this before and am unsure if the uncharacteristically hot weather here in the UK is frying my brain.

I have a basic datasource that grabs blog articles based on their title, via a page parameter.

i.e. the URL is formed as follows:

http://www.domain.tld/blog/$category/$article/

The datasource gets entries by title, using the $article parameter.

The issue is that if there's no $article parameter (i.e. if the URL is just for a category: http://www.domain.tld/blog/$category) it just returns all the results in the XML. Which seems counter intuitive and I'm sure doesn't normally happen. I've asked it to go to a 404 if no results are found, but the problem is even if there is no result it still finds results… all of them.

If I put a bogus string in there it fails, because it can't find a result, but it seems to interpret '' (i.e. nothing) as 'everything'.

Ideas?

Does it work if you set the Required URL Parameter of the data source to $article?

And have you set a fallback-value for your parameter-filter?

like {$article:0}

:)

Thanks.

@Roman I wasn't aware of that technique actually. I don't need it here, but handy to be aware of, thanks!

@nathanhornby you’re welcome! ^_^

@Roman I wasn’t aware of such a technique either: I’ll make treasure of it too, thanks!

Bugger.

Actually neither will work.

The problem is that '$article' isn't actually required; as you might want to view all articles by category (uses a different datasource).

So I just need a blank result for that variable to return no results, rather than all of them,

Mmm, is there any reason why you’re not having two separated pages, one handling the list of the articles (which can eventually be filtered by $category) and one the single article?

• http://www.domain.tld/blog/$category
• http://www.domain.tld/blog/entry/$article

Mostly to avoid the redundant 'entry' in the URL actually, and so that the category is part of the URL structure (SEO, readability etc.)

So basically what happens is the 'blog' page contains two templates, which are triggered by the presence of the 'article' parameter.

Which works fine, incidentally - the only issue is the unnecessary grabbing of all articles when that article parameter is blank.

So it's not a real problem, in the traditional sense!

Sounds strange as both techniques (defining a fallback of "0" or setting a required parameter) always have worked as expected for me - with returning an error in the datasource instead of all entries if the parameter has no value.

Could you post a screenshot of your datasource-editor?

The problem is that '$article' isn't actually required; as you might want to view all articles by category (uses a different datasource).

But "Required URL Parameters" are defined for single datasources, so it doesn't matter if another DS doesn't need it. In your setup it should be a required parameter for your article-DS if I understand it right...

Mmm, I think the data source is behaving properly, because:

• in case the URL is http://www.domain.tld/blog/, the data source returns all the articles (no $param is filtering them)
• in case the URL is http://www.domain.tld/blog/$category, the data source returns all the articles being part of that $category ($category is filtering them)
• in case the URL is http://www.domain.tld/blog/$category/$article, the datasource returns just one article being part of that $category and having that $title ($category and $title are filtering it)

I think you’re looking for a way to make $article a required URL parameter only if $category is present but, as far as I know, it’s not possible….

Mmh.. but as far as I understand Nathan is using different datasources for the "list" views as he said...

...as you might want to view all articles by category (uses a different datasource).

So if the DS described in the first post should only be needed for fetching a single full entry if an $article-param is set this should be perfectly possible.

Ah! You’re right! I misread what Nathan wrote and I thought he was using the very same data source for handling everything.

Yes, I agree with you it should be perfectly possible, but I have another concern: if in the single article data source $article is set as Required URL Parameter and Redirect to 404 page when no results are found is checked, wouldn’t the viewer be redirected to the 404 Error / Page not Found page when s/he tries to merely view the list of the articles (http://www.domain.tld/blog/), since an empty result will be returned when $article doesn’t have a value?

Hi guys,

Sorry for my absence.

@theBigMandarino - you're absolutely right.

When setting $article to 'required' the issue becomes that if a user visits domain.tld/blog/category/ it forwards to a 404, as the required 'article' param isn't being defined.

@nathanhornby, I fear I cannot be of any more help because I have run out of ideas: the only way coming to my mind to solve such a problem would consist in having two different pages (list and article).

The cons, as you already pointed out, would be giving up the neat URL structure; the pros would be handling 404 errors properly, optimizing the use of data sources (no data source is going around in circles since they are being attached to different pages) and simplifying the templates (no need to switch from one to the other depending on the presence/absence of a URL parameter).

@nathanhornby I remember this being discussed on github between @brendo, @designermonkey and myself. This is a symphony bug. By setting the $article to required it should not throw a 404

I'm not entirely sure if this was committed to the latest version of symphony, however I believe there is a patch to fix this behavior.

Thanks for the follow up @gunglien, and no problem @theBigMandarino - appreciate your help!

To some extent this is also a data structure issue (if we even consider it an issue, as the only negative is an unnecessary call to the DB) - I think I could have achieved the same with a single datasource and avoided this trouble, but would have to experiment to confirm.

Cheers all!

There you go https://github.com/symphonycms/symphony-2/issues/1646 Seems like it should have been pushed in the latest release.