You are not logged in.
Seems to be a bit quirky
Ah, yeah, ahem. Forgot to ask you to re-read the note (now under a bold heading :-) from v0.2. That will probably account for 90% of the quirks. Most certainly points 1 and 2. I’ll make a note of this in the actual plugin help docs too: I forgot, ooops.
Point 3 sounds like I’m not escaping the apostrophes properly in the content, but I’m pretty sure I applied the proper functions… or at least I thought I did. I’ll see if I can replicate the problem with your text on my dev box and go from there.
I’m not quite sure I understand point 4. The
<txp:smd_featured /> tag will process all featured articles in its container the same way. The chances are that the problem is also to do with the ‘stickiness’ of the prefs and things getting confusing. My advice is to do the following:
(OR install the latest SVN and then perform the last step on your featured articles, since the prefs stay put when you apply them so it’s a bit easier!)
The act of hitting Save against each article will apply the current Textile settings to that featured article. It’s like if you alter the default ‘Use Textile’ settings in your TXP Admin prefs: it doesn’t go back and change any of your articles. They still have Textiled (or non-Textiled) content as they always did. The setting only affects the articles when things are saved from that point forward. Does that make sense?
Thus if you change the Textile setting and want to apply it to all your existing featured articles you have to visit each article and resave it. Normally this isn’t a major hassle ‘cos you switch it on or off once and don’t touch it again. Even if you have already featured some articles there’s normally only a handful so I figured it wasn’t worth factoring an ‘apply to all’ button in the interface. The SQL error may well be getting in the way here, btw, because if you save the featured article and it doesn’t make the changes in the database then it’ll still be in the ‘old’ state which could confuse matters somewhat.
I kinda did the docs in a hurry so perhaps I’ll revisit them and make that clearer too. At the same time I’ll see if I can repeat the SQL error and fix that. Dunno how I managed to let that one slip through the net. Shod-tastic, sorry.
D’oh! Missed a function if you try and save a non-textiled description with apostrophes in it. Fixed in v0.22. Also updated the docs a bit. Thanks bg.
Thanks, Sir Bloke!
That did the trick. I had read the (now boldly marked) IMPORTANT note you mention in your first paragraph but somehow it did not fully register. Instead of going back to the Plugins tab, I clicked the Featured Articles tab to refresh the prefs. Duhhhhh…. (Or maybe Dunce is more appropriate).
All is working beautifully now, so it’s time to take it live! You are a Prince among princes for your wonderful assistance.
I’m doing this in a sidebar that is used through most of one site I work on:
<div id="recent-features"> <txp:smd_featured break="li" unlabel="Recent Features" labeltag="h2" sort="posted desc" wraptag="ul"><txp:permlink><txp:title /></txp:permlink></txp:smd_featured> </div> <!-- EO #recent-features -->
<div id="recent-articles"> <txp:smd_unfeatured break="li" label="Recent Articles" labeltag="h2" sort="posted desc" wraptag="ul"><txp:permlink><txp:title no_widow="0"/></txp:permlink></txp:smd_unfeatured> </div> <!-- EO #recent-articles -->
It works great and awesome, except in individual article context, where it lists the current article— seven times in the first
div, using the given
breaks, and once in the second
div, with no
break. The behavior is identical regardless of whether the current article is featured or not. Is this expected behavior? Is there any way to make a smd_featured article list appear on an individual article page?
Time to revert to the article_custom mashup I had before. Let me know if you need a tagtrace.
Thanks, and warmest regards!
I was just about to post the same thing, John. For now my workaround is just to not have any featured articles show up on individual article pages. I can post code and such, too, but I suspect it’s the exact same problem.
v0.30 is released which attempts to tackle my foolhardy use of the article tag inside the guts of the plugin which, of course, anybody but me could have foreseen would wreak havoc on individual article pages. Thanks to johnstephens for bringing this to my attention.
This raised some other interesting issues with the plugin. Chiefly, since I’m using
article_custom() and that has some default attributes set, your lists will be governed by the defaults in that tag. To counter this and make it more obvious what’s going on I’ve set the
limit to a default of 10 (the same as article custom). I’ve allowed the
time attribute to fall through to the article custom as well.
I spotted this by mistake when I specified
time="any" during one of my tests: the plugin was pulling out all the correct articles but only displaying the
past ones due to article_custom’s default setting. This should now be fixed and I hope this version is slightly more deterministic!
Since there’s a chance the changes will alter your existing output slightly I’ve bumped the major version number. Have fun.
Thanks for the update, Stef. I was just about to try something like John Stephens did. And now I won’t be confumbulated when it doesn’t work, because… of course now it will work!
I love this plugin! My entire front page runs from it. You truly are the Prince of Blokes!;)
Dare I ask????
Stef, one thing that would make this plugin even cooler than a Mint Julep would be some kind of date control override.
For example… I’d like to set my Featured Articles up to be selected at random by the plugin, EXCEPT during one specific time span. During that time span (Christmas day, for instance), I’d like to feature only one specific Featured Article that’s specific to the time span (to continue this example, it might say “Merry Christmas”), instead of the usual order of randomness that would occur outside of that particular time span.
The above description may sound complicated, but the effect could probably be accomplished with some sort of a date flag that could be attached to the plugin (on the “Edit” screen) which automatically triggers it into “Posted desc” mode instead of “rand()” on a given date. Then it would select the most recent article from the database. And when writing that particular article I would set the Publish date to whatever target date I want the the plugin to start showing it.
Then the “Trigger Date” would pop the Plugin out of “rand()” selection mode into “Posted desc” selection mode and the specific article I want featured would be the only choice for “Posted desc” until it expires according to whatever Expire Date I set in the Article Write tab. At which time the plugin could (though it wouldn’t have to) revert back to “rand()” selection.
Is this making sense? Is it feasible? Or is it beyond the scope of what a single plugin could accomplish? Or could I accomplish the same thing by combining SMD_Featured with SMD_If? Or am I completely whacko and should stop smoking whatever it is I’m smoking?
Just asking!;) Feel free to call me nuts (or anything else), but I had to ask.
Thanks again for a wonderful plugin!
Last edited by bg (2010-10-08 03:11:34)
Dohhhh…. slap me upside the head with a wet tortilla, please!
Must’ve been noodling this around in my sleep because I woke up this morning realizing it could be accomplished simply by setting up two different TXP Forms, one for Posted desc and one for rand() selection; then using a simple PHP date script to call the appropriate form.
That would allow me to make it completely automatic (and idiot proof for those who contribute to the site) — a definite plus.
Now I’m embarrassed for wasting bandwidth with the question! Too many hours staring at the screen, maybe?
But thanks for reading, any way;)
You’re right that date-based article selection is probably outside the scope of this plugin. Glad you figured it out in the end, though. Having a few forms is a good way to manage it. I’m sure there’s a generic date plugin out there somewhere (I think Rick Silletti has one? ras_if_date or something?) But a jot of PHP will do the job as you found.
Incidentally, in addition to the slightly awkward smd_calendar (still in need of a rewrite) I had a stab at a sort of date-ish plugin for counting down to specific events, unsurprisingly called smd_countdown. So if you wanted to pimp your featured articles in advance or tease people with what’s to come you may be able to use that plugin or smd_horizon in conjunction with smd_featured. Never tried it, but it might work.
Failing all that, smd_if is perhaps a reasonable alternative. Not sure how it’d work off the top of my head, but it’ll probably be able to manage it if you can get at the relevant variables, though my guess is the raw PHP will be more efficient (depending on what you want to do with it all).
Last edited by Bloke (2010-10-08 16:33:54)