Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
[wiki] image, article_image, and documentation
Reviewing image(), article_image(), and their documentation (I’m working on an image plugin), I noticed some inconsistencies.
This FAQ states that an article image assigned by URL can use any absolute URL, including root-relative URLs such as “/images/foo.png”. This is correct. The relevant TextBook entry says this must be the full URL, which is not correct. I’ll correct the TextBook entry, but wanted to air it here first in case I’m overlooking something.
That TextBook entry also says you can assign the article image by name. This is incorrect. -I wonder if this is an oversight in the article image tag?-* Whereas <txp:image /> allows you to specify an image by its name (i.e., the name assigned to the image on upload), <txp:article_image /> assumes that any non-numeric value for article_image is a URL (Txp versions 4.0.6 and 4.0.7).
(The relevant TextBook tag reference is correct as to current function.)
* As usual, I’m wrong and the devs got it right: name can be anything, e.g. could be “http://foo.bar”, so it’s either allow article image by name or URL, but not both.
** Then again, I suppose you could: if the value is numeric, try it as an image id first, if no image then try it as an image name. If it’s not numeric, try it as a name first, if no image then assume it’s a URL. It’s more database calls but not too bad.
Last edited by jsoo (2009-01-18 14:22:13)
Code is topiary
Offline
#2 2009-01-16 19:35:53
- saccade
- Plugin Author
- From: Neubeuern, Germany
- Registered: 2004-11-05
- Posts: 521
Re: [wiki] image, article_image, and documentation
Hi jsoo,
thanks for the corrections.
Michael
Offline
Re: [wiki] image, article_image, and documentation
Happy to do so. I’ve also been correcting entries that are wrong on how class and html_id interact with wraptag. At some point I’ll probably go through all the entries that contain wraptag.
Code is topiary
Offline
#4 2009-01-19 12:39:44
- saccade
- Plugin Author
- From: Neubeuern, Germany
- Registered: 2004-11-05
- Posts: 521
Re: [wiki] image, article_image, and documentation
I’m very curious: What image plugin are you working on?
Offline
Re: [wiki] image, article_image, and documentation
A generalized replacement for <txp:image />, <txp:thumbnail />, and <txp:article_image />, using “image forms” in the same manner that <txp:article /> and <txp:article_custom /> use article forms, allowing for multiple article images, image galleries controlled through forms, etc.
Code is topiary
Offline
Re: [wiki] image, article_image, and documentation
jsoo wrote:
A generalized replacement for
<txp:image />,<txp:thumbnail />, and<txp:article_image />, using “image forms” in the same manner that<txp:article />and<txp:article_custom />use article forms, allowing for multiple article images, image galleries controlled through forms, etc.
Sounds intriguing. You mean a bit like smd_gallery?! Or the proposed image patch which mimicks the upm_image concept for the core using forms and containers to set up image galleries? ;-)
Last edited by Bloke (2009-01-19 15:26:48)
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
Re: [wiki] image, article_image, and documentation
I can’t say I have fully grokked either your gallery or proposed patch, as doing so would require significant study. I suppose I’m aiming in the same general direction, but perhaps with a different conceptual approach. De gustibus and all that, but when I see a tag with 40 or so attributes I know it’s not for me. I don’t mean that as a slight against your very popular plugin. Your own support page begins:
[If you] crave something a little more esoteric or complicated, this might just be the plugin for you.
whereas I crave the opposite: something simple, with familiar attribute names, and that feels like an extension of core.
Code is topiary
Offline
Re: [wiki] image, article_image, and documentation
jsoo wrote:
when I see a tag with 40 or so attributes I know it’s not for me
OT: lol, I know. Sorry about all that. You’d better not look at smd_calendar then: it has over 50!
To be fair to both plugins, you can run them with zero, one or two attributes and get pretty much all the functionality you need for 80% of situations. The rest just allows the plugin to grow with your needs or to tweak stuff when all else fails.
something simple, with familiar attribute names, and that feels like an extension of core.
Totally cool. The more plugins the merrier I say. But please check out the patch if you can. It has a very limited set of attributes and smells very core-ish. If your plugin ends up being super-core worthy, feel free to modify the patch to make it more usable. I think for consistency’s sake that images should be treated in a similar manner to files/links and that’s all the patch aims to do. But it seems I’m alone in this quest… or my patch is not suitable yet, I’m not sure which :-(
Anyway, sorry to hijack the thread.
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
Re: [wiki] image, article_image, and documentation
Bloke wrote:
You’d better not look at smd_calendar then: it has over 50!
In fact I have the support page for it open right now; iCal integration is another thing I’ve been thinking about. I’m currently using an ancient, embarrassingly crappy & ludicrously un-generalized Perl script of my own devise to manage a calendar for one particular Txp site. The horror…
To be fair to both plugins, you can run them with zero, one or two attributes and get pretty much all the functionality you need for 80% of situations. The rest just allows the plugin to grow with your needs or to tweak stuff when all else fails.
A very valid approach. I just don’t think it’s the core Txp approach. Small example: I too considered something like <txp:soo_image_field name="field" /> in place of a string of tags such as <txp:soo_image_author />, <txp:soo_image_category />, etc., but decided that the single-purpose tags are _The Textpattern Way_™.
Anyway, sorry to hijack the thread.
Weren’t you; ‘twas already hijacked, by me as much as anyone. Bad me, bad!
And yes, I will look at your proposed patch.
Last edited by jsoo (2009-01-19 16:50:42)
Code is topiary
Offline
Re: [wiki] image, article_image, and documentation
jsoo wrote:
I too considered something like
<txp:soo_image_field name="field" />in place of a string of tags such as<txp:soo_image_author />,<txp:soo_image_category />, etc., but decided that the single-purpose tags are _The Textpattern Way_™.
Spookily enough that’s exactly what I did in v1 of the patch but it was pointed out (correctly imo) that having that many tags adds too much bloat for very little gain, so I swapped most of them out for a ‘one or two tags to output everything’ approach. The jury is out on which way is “right”. I guess it comes down to balance.
Last edited by Bloke (2009-01-19 17:33:50)
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
Re: [wiki] image, article_image, and documentation
Great minds and all… I suspect power users would love generalized tags while new users find single-purpose tags easier to deal with. As you say it is a question of balance. At one extreme one could have
<txp:get type="article" item="title" />
At the other:
<txp:image_author_first_name />
;-)
Code is topiary
Offline