Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Images are 1st class citizens of TXP
Since there’s been very little reaction and the one or two concerns raised here or privately have been that it might be too complicated for core use, let me rephrase the question:
Would anybody miss the ability to specify an AND/OR scenario in this tag if I removed it?
Removing the ‘image pool’ idea means that all filter attributes are applied on top of one another and only images that match all the criteria are returned. In other words, id
, name
, category
, author
, realname
, ext
and thumbnail
work like they do in other tags.
If the tag is reverted to this more TXPish behaviour then anybody wanting anything more complicated, will have to use a plugin. OK? Or not?
Last edited by Bloke (2010-03-24 23:28:05)
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
#62 2010-03-24 23:41:07
- rsilletti
- Moderator
- From: Spokane WA
- Registered: 2004-04-28
- Posts: 707
Re: Images are 1st class citizens of TXP
Bloke
I’ve cloned a plugin that includes the and_or att, and if_first | if_last options, from the commit prior to the pagination additions. It runs as expected under Ver 4.2.0 and it would provide for the needs of anyone interested in the added functionality. Updating another for the next release would also work.
The primary question is whether or not you want your code used that way by a third party.
Offline
Re: Images are 1st class citizens of TXP
Bloke wrote:
Since there’s been very little reaction and the one or two concerns raised here or privately have been that it might be too complicated for core use
Sorry. Too busy lately to do more than skim, and didn’t want to chime in without due consideration. Unless you are going to allow wildcards, partial matches, regexp, or what have you, I don’t see enough benefit from the AND|OR
switch to outweigh the additional complexity.
Code is topiary
Offline
Re: Images are 1st class citizens of TXP
Bloke wrote:
If the tag is reverted to this more TXPish behaviour then anybody wanting anything more complicated, will have to use a plugin. OK? Or not?
I personally do like your latest additions. But, IMO they are way too complex: As I earlier said something that I would except finding from smd_plugin. Don’t take me wrong, they are great but just that… why.
What comes to shortage of comments, possible because this isn’t what userbase wants? Maybe they are fine with the current smd_gallery and what not. When you look at feature requests they seem to want better image management and handling to the backend not to the tags which can only be used by web developers, not the actual content authors. Way that they can do uploading, content and common tasks at once.
Offline
Re: Images are 1st class citizens of TXP
Bloke wrote:
If the tag is reverted to this more TXPish behaviour then anybody wanting anything more complicated, will have to use a plugin. OK? Or not?
From a gut feeling: OK. I once dabbled in improving image-related tags – and then came soo_image, adding yet another item to the vast collection of all thing gallery we already have at our disposal. From my POV, the area of images and galleries and what not is too diverse to find a on-size-fits-all solution. Look, even those lightbox effect scripts are legion nowadays.
Offline
Re: Images are 1st class citizens of TXP
rsilletti / Gocom /jsoo / all
Thanks. You’re all right. I will strike the complexities from the code forthwith. In order to keep the auto-article-image stuff though, I think the context
wil have to stay for the time being. If that feels too much I can kill that as well.
Rick, by all means clone the code. It’s there for your consumption. I’m thinking of stealing your date difference class for smd_calendar 8o)
Gocom wrote:
better image management and handling to the backend not to the tags
Yeah, point taken. It’s coming, just taking me longer than expected.
My aim for the front-end tags was twofold:
- To introduce
$thisimage
so images are brought into alignment with the existing content types - To bring the best parts of upm_image / soo_image to the core so that
$thisimage
can be taken advantage of and we can get at the image fields natively. It makes little sense to have a caption if we can’t display it without a plugin!
I shall make amendments today, test and release. Watch this space, and thanks again for your thoughts / helping me see the light.
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
Offline
Re: Images are 1st class citizens of TXP
Aaaaaand it’s gone. Sanity is restored.
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
Offline
#70 2010-07-06 10:07:47
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: Images are 1st class citizens of TXP
Any chance of a new <txp:image/>
attribute to disable the output of HTML width="xx" height="yy"
?
Offline
Re: Images are 1st class citizens of TXP
gomedia wrote:
Any chance of a new
<txp:image/>
attribute to disable the output of HTMLwidth="xx" height="yy"
?
For what purpose? (forgive my ignorance). If it’s for manual resizing, you might like to be on the beta list for smd_thumbnail. Get in touch if you want to try it out and you’re running bleeding edge SVN.
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
#72 2010-07-06 10:41:05
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: Images are 1st class citizens of TXP
Bloke wrote:
For what purpose?
For elastic/stretchy/bendy layouts where images are resized in CSS according to ems or percents.
With the HTML width & height attributes:
img { width:20em; height:auto }
without width & height:
img { width:20em }
Saves my sanity & some code bloat. Both upm_image
& soo_image
have options to disable width/height in HTML <img>
tag.
Offline