Specify article_custom limit AND check for non-empty custom field?

artagesw · 2009-07-03 17:17:22

Bloke wrote:

artagesw’s solution is by far the simplest, but if you’re already using the categories for other things you’re stuck …

If you don’t want to burn categories for this, keywords provide another alternative.

jsoo · 2009-07-03 22:09:05

alannie wrote:

I’m a huge fan of your plugins and have soo_toc and soo_image installed as well. When are you adding a “Donate” button on your site? :)

Thanks alannie, very kind! I suppose if my plugin download rate and/or support thread traffic goes way up I’ll consider it, but for now I’m happy to share these plugins that I am finding useful myself. Of course, a donation to Txp is always welcome…

jsoo · 2009-07-03 22:37:15

Hmm, I’m taking the long way round to find a simple solution, as usual. Guess what:

<txp:article_custom limit="3" video_id="_%" />

works. Might just have to mothball that plugin.

maniqui · 2009-07-03 22:51:47

^^ what?! _% works like a wildcard? do you know the explanation?

jsoo, thanks for sharing this discovery…

jsoo · 2009-07-03 23:00:27

See the ‘like’ function in MySQL, about a page down describes the wildcards. "%" is the equivalent of ".*" in PCRE syntax. "_" is the equivalent of ".". So "_%" is equivalent to ".+".

els · 2009-07-03 23:17:55

OMG, jsoo, you just started a whole new Txp era! Thank you :)

artagesw · 2009-07-04 00:09:33

Tread carefully there. That is likely an “unintended feature” that happens to work now but could break in the future. For one thing, it is MySQL-specific, which is something to watch out for if you want to maintain the flexibility of changing to a different database backend in the future.

maniqui · 2009-07-04 00:20:20

Yes, some words from wet about this “unintented feature” could be helpful to know if it’s safe to use it in the long run.

jsoo · 2009-07-04 00:35:04

From a quick survey the same pattern (and the operator LIKE) will also work in SQLite and PostgreSQL.

Edit: And I wouldn’t call it “unintended”. It was certainly intended by whoever chose to use LIKE instead of =, as shown by the following comment in the function in question (buildCustomSql() in publish.php):

# nb - use 'like' here to allow substring matches

Last edited by jsoo (2009-07-04 01:52:15)

artagesw · 2009-07-04 03:16:40

LIKE and the “%” and “_” characters are standard SQL, but not always consistently implemented. Also, the assumption that the semantics of a tag attribute are equal to the semantics of SQL is not necessarily a good one. It can make for fragile code. Tags serve as an intermediary between you and the storage engine (database) for a reason. Pierce that veil at your own risk. ;)

jsoo · 2009-07-04 11:57:06

There’s also sort. Used to be split into sortby and sortdir attributes; now we’re expected to put valid ORDER BY expressions into sort. Having separate attributes is, I think, closer to your idea of tags as intermediary. Which I agree with, but I also agree with keeping the number of attributes in check. Something’s gotta give.

And there’s smd_query. Probably lots of MySQL-specific Txp code out there now. Again, I’m not saying this is good in itself, but by gum it works. Undoubtedly some of us will have some extra work, some day, prepping an existing site for conversion to a different DB engine. But probably not much. The smd_where_used plugin will be a handy helper for that task…

artagesw · 2009-07-04 17:10:56

jsoo wrote:

There’s also sort. Used to be split into sortby and sortdir attributes; now we’re expected to put valid ORDER BY expressions into sort.

Yeah, there do seem to be a few instances where database dependency has crept into core. Not a good thing IMHO.

And there’s smd_query. Probably lots of MySQL-specific Txp code out there now.

Sure, but that’s a plugin, and plugins are by definition a compatibility risk. I’m more concerned with the core and being able to move it forward effectively without breaking existing sites.

Gocom · 2009-07-05 02:09:12

artagesw wrote:

Yeah, there do seem to be a few instances where database dependency has crept into core. Not a good thing IMHO.

Oh, yeah, conditionals or a parser for the values, which IMHO makes it more limited and slower.

artagesw wrote:

plugins are by definition a compatibility risk.

Lol’d.

artagesw · 2009-07-05 03:20:12

Gocom wrote:

Oh, yeah, conditionals or a parser for the values, which IMHO makes it more limited and slower.

By that argument, you might as well throw away the entire Textpattern tagging system and write straight PHP for your templates. Compared with PHP, Textpattern tags are slow (require an additional layer of parsing) and limited. But there are benefits to tags that outweigh these costs, so we trade off some performance and flexibility to gain these benefits.

artagesw wrote:

plugins are by definition a compatibility risk.

Gocom wrote:

Lol’d.

It’s true. Plugins are essential, yes. But when you decide to use them, you must be prepared for potential problems down the road. From Textbook:

When a webmaster uses a plugin to achieve a goal on its website, if that goal is “critical” then he should seriously think it through. Because if:

a new Textpattern version breaks the plugin

the plugin is not maintained anymore

a security flaw is discovered with it

and the plugin author does not (or can’t) fix it, the site may not function as you intend.

Gocom · 2009-07-05 03:44:09

artagesw wrote:

gain these benefits.

But we need to weight the benefits. And IMHO, I wouldn’t put that little sort value in the category of benefits. Also it will disable MySQL version destricted hacks, that for examle right now make some websites work. For example sorting of varchar fields as ints.

artagesw wrote:

It’s true. Plugins are essential, yes. But when you decide to use them, you must be prepared for potential problems down the road.

I just lol’d for your definition, chill out :). I know that, or then I’m been on ~~drugs~~ donuts for the last five years. Donuts…

Textpattern CMS

Textpattern CMS support forum

#16 2009-07-03 17:17:22

Re: Specify article_custom limit AND check for non-empty custom field?

#17 2009-07-03 22:09:05

Re: Specify article_custom limit AND check for non-empty custom field?

#18 2009-07-03 22:37:15

Re: Specify article_custom limit AND check for non-empty custom field?

#19 2009-07-03 22:51:47

Re: Specify article_custom limit AND check for non-empty custom field?

#20 2009-07-03 23:00:27

Re: Specify article_custom limit AND check for non-empty custom field?

#21 2009-07-03 23:17:55

Re: Specify article_custom limit AND check for non-empty custom field?

#22 2009-07-04 00:09:33

Re: Specify article_custom limit AND check for non-empty custom field?

#23 2009-07-04 00:20:20

Re: Specify article_custom limit AND check for non-empty custom field?

#24 2009-07-04 00:35:04

Re: Specify article_custom limit AND check for non-empty custom field?

#25 2009-07-04 03:16:40

Re: Specify article_custom limit AND check for non-empty custom field?

#26 2009-07-04 11:57:06

Re: Specify article_custom limit AND check for non-empty custom field?

#27 2009-07-04 17:10:56

Re: Specify article_custom limit AND check for non-empty custom field?

#28 2009-07-05 02:09:12

Re: Specify article_custom limit AND check for non-empty custom field?

#29 2009-07-05 03:20:12

Re: Specify article_custom limit AND check for non-empty custom field?

#30 2009-07-05 03:44:09

Re: Specify article_custom limit AND check for non-empty custom field?

Board footer