Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2019-10-11 14:15:12

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,945
Website

Re: custom field value as a variable for link and category name

:-) You’re dangling tantalising prospects here!

Just to clarify:

It does mean this, indeed, even in <txp:article />.

In txp:article (without _custom) we don’t usually include any filtering attributes. Are you saying that txp:article already intelligently responds to custom_field filters in the URL? Or do we need to explicitly add those attributes to txp:article?

The idea is that (valueless artist) …

Is that future music, or already possible?


TXP Builders – finely-crafted code, design and txp

Offline

#12 2019-10-11 14:31:19

etc
Developer
Registered: 2010-11-11
Posts: 3,940
Website

Re: custom field value as a variable for link and category name

jakob wrote #319660:

In txp:article (without _custom) we don’t usually include any filtering attributes. Are you saying that txp:article already intelligently responds to custom_field filters in the URL? Or do we need to explicitly add those attributes to txp:article?

The cf filtering is not automatic (unlike section, etc), since it’s not always desirable, but we can add it explicitly.

Is that future music, or already possible?

The first point is already in 4.7, the rest to decide.

Offline

#13 2019-10-11 21:03:24

etc
Developer
Registered: 2010-11-11
Posts: 3,940
Website

Re: custom field value as a variable for link and category name

The future is coming.

Offline

#14 2019-10-18 08:56:54

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,945
Website

Re: custom field value as a variable for link and category name

etc wrote #319676:

The future is coming.

Hi Oleg,

I’ve tried this out now and find that I am now not getting custom_field filtering at all, with or without the attribute. Checking the debug trace, the SQL statement has no custom field filter. Just section, limit and the usual date and status conditions.

Looking at the code, is the syntax correct with if and switch run into each other in the same if-condition? Maybe it just looks unfamiliar to me. I tried putting the switch within the if brackets and dmp-ing messages to see which case applies for

<txp:article_custom article_front_display="Yes" section="english" limit="1"> … </txp:article_custom>

(where “article_front_display” is a yes/no custom field) and get the case that’s not covered: switch case = true; if case = else (i.e. if and elseif are both not met). Does that help at all?


TXP Builders – finely-crafted code, design and txp

Offline

#15 2019-10-18 10:38:38

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,789
Website

Re: custom field value as a variable for link and category name

jakob wrote #319762:

is the syntax correct with if and switch run into each other in the same if-condition?

It’s syntactically correct – an if() doesn’t need a brace if there’s “one statement” within it – and the switch counts as such in this scenario – but since we’re adhering to PSR-2 wherever we can, we should use braces for the if() { ... } construct for clarity. In the same way we shouldn’t be using:

if ($condition) return;

and:

if ($condition) continue;

in the code any more. Although it takes up more space, we should be using:

if ($condition) {
    continue; // Or return or whatever
}

It simply makes it easier to read and introduces fewer potential mistakes if someone decides in future that we need another action inside that conditional, because:

if ($condition) $counter++; continue;

or:

if ($condition) $counter++;
    continue;

is the same as:

if ($condition) {
    $counter++;
}

continue;

which is highly likely not what was intended.

As for the reason it’s not working for you and bringing in the custom field data, I’ll have a play with it when I get a chance, though Oleg will probably beat me to it!


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#16 2019-10-18 11:25:03

etc
Developer
Registered: 2010-11-11
Posts: 3,940
Website

Re: custom field value as a variable for link and category name

D’oh! Of course, switch comparison is not strict, so everything not empty matches true. Thanks Julian, corrected.

Offline

#17 2019-10-18 11:31:29

etc
Developer
Registered: 2010-11-11
Posts: 3,940
Website

Re: custom field value as a variable for link and category name

Incidentally, I have removed unregistered tags fallback, but maybe it’s time anyway? Most plugins should have already updated their code.

Offline

#18 2019-10-18 11:37:59

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,789
Website

Re: custom field value as a variable for link and category name

etc wrote #319766:

Incidentally, I have removed unregistered tags fallback, but maybe it’s time anyway? Most plugins should have already updated their code.

Yeah, spotted that… *frantically checks plugin code* … Uh-oh.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#19 2019-10-18 12:24:57

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,945
Website

Re: custom field value as a variable for link and category name

etc wrote #319765:

D’oh! Of course, switch comparison is not strict, so everything not empty matches true. Thanks Julian, corrected.

Thank you so much! That restores functionality :-)

I haven’t tried the attribute-less variant yet. I realise I misunderstood its use. It’s not “if there’s any value for it” but “if it’s the same as the current article” or “if it’s been passed as an urlvar”.

Incidentally, I have removed unregistered tags fallback, but maybe it’s time anyway? Most plugins should have already updated their code.

Yes, that’s about time. One minor thing: that would be great as a separate commit with an appropriate description for better findability later though, as it will no doubt result in forum queries. Sometimes it’s useful to be able to point to when things changed.
As that was the most recent commit, perhaps you can still revert and re-commit separately?

Bloke wrote #319767:

Yeah, spotted that… frantically checks plugin code … Uh-oh.

You have such a tremendous collection, you may still have one or two without registered tags. Thanks for the explanations above. Makes sense!


TXP Builders – finely-crafted code, design and txp

Offline

#20 2019-10-18 12:57:06

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,789
Website

Re: custom field value as a variable for link and category name

jakob wrote #319768:

you may still have one or two without registered tags.

I count five, excluding forks. Not as bad as I thought. I’ll tend to those asap.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB