I simply do not understand why it is necessary to be abusive to someone who points out that wholesale and widespread use of plugins has some downsides. The obvious one occurs at the theme dev / plugin interface. If one user has multiple plugins and multiple themes – then each time they fit a new theme they need to copy the plugin calls into each relevant template in the new theme. Furthermore a theme dev needs to make a strategic choice about whether certain plugins should be required to run the theme. Generally theme dvs chosse not to, for obvious reasons. But there is absolutely no need to be offensive to anyone who spends time sitting looking at both sides of this equation. Furthermore it is a fact that many plugins were conceived to expand capabilities in the core functionality when that functionality did not exist in WP. Sometimes it has been adopted by the devs in the core. So we need to be discerning about recommending plugins which have been overtaken. We also need to keep the user informed where he has a choice. What we should not be doing is allowing our latent paranoia to disrupt the forum. And vkaryl – your contribution to this dialogue has been unhelpful to say the least.
Root – hope you didn’t feel >I< was in any way abusive! I agree there are many options for users.
However, I also want to point out that many plugins that add OUTPUT may need you to modify templates — at least until there’s a meta-template system for ‘sidebar modules’ and the like. On the other hand, plugins like CG-PostOrder, or CG-Related, work 100% independent of the theme/template in use — just activate the plugin.
I’d go so far as to say I don’t like themes that require certain plugins (aside from implementing core theme functionality). Let users add whatever plugins they want, whatever content they want.
Yes, there are cases where things benefit from moving into the core. But plugins that don’t require any theme modification, and work across themes, are what much of the ‘core’ should evolve into. Let more of the functionality of WP be in plugins, so that users can just turn it on and off. Don’t hide such things as checkboxes, when they could be modules that aren’t even loaded into memory… 😉
Just IMHO! 😉
-d
Certainly not David. You have been a fine model as always. There is a lot more to the strategic choices about plugins than some folk are willing to face up to. I love them myself. But I try to code where I can. Horses for courses. But the tone in this thread really disturbed me.
Had the same problem – The solution =
Post your post / Save it
Go back to edit it (advanced editing)
And the sticky checkbox should come up.
If not fill in the Custom Field with the Value:
Key: Sticky, Value: 1
(www.usayd.com) i’ve currently got one up
Man did I open up a can of worms! The plugin does work. it just doesn’t put the check box in the write advance of a new post. It is there when editing or publishing from a draft. I don’t know why I didn’t know that from the start.
As for plugins, I think they are a great idea. Obviously the deevelopers do as well or they wouldn’t have that functionality built into WP.
As for coding? I think programmers who love to code should use coding solutions. I think that is really what drives the desire to do it your way and that is fine.
frankly I do it both ways. I have figured out enough php to customize my blog to do what I want it to do on a basic level. But when there is a plug-in that does whta I want then I am more then happy to use it.
As for you coders out there why don’t you help me out on the quick tabs plugin? It puts buttons on the comment page but not on the comments popup page and for the life of me I cannot figure out how it is even calling the comments in the plugin.
Well, that was certainly an interesting read, and I don’t even know what adhesives is! (well, I do now…)
:o)
Just out of curiosity, what percent of plugins are NOT cross-theme compatible? So far the only thing I’ve found that isn’t cross-theme compatible are the hacks or plug-ins that predate the one-click feature, those that require me adding code to sidebar.php or some other page. Even though I only use one theme and don’t give my readers the option to switch, I might want to do that in the future and I hate the thought of having to go through several pages trying to find my add-in code several months after I first typed it in! Give me plug-ins any day…
yep i agree, plugins just enhance what is already really good! And they are customizable, meaning that if you have a specific thing you want to do that no one else would want, you can either program a plugin for that or you can find one!
In response to Vkarly not wanting to use the ‘on a plate’ method to post stickies — I realize that to some this method may be confusing. However, in the comming days I will re-release that tutorial showing exactly how one can do it step for step with the default (kubrick) theme. Litterally, its as easy as a couple of cut and pastes.
What is “template dependant,” is how your posts are formated for viewing, not how the sticky code itself works.
If there is any “cut and paste”, that becomes “template dependent”. i.e., if I switch templates, I lose my stick functionality if I don’t go cut and paste again. With a plugin like CG-PostOrder, the functionality really is (well 99%) template independent — so long as your template uses the standard posts loop. 😉
-d
Here it is anyway, for those that dig up this thread.
brianbonner,
I, too, was puzzled when Adhesive (2.1 beta on WP 1.5.1.2) worked so well at my website, but failed to give us a Sticky box on a website I set up for a good friend.
Root’s approach is fine for some. But if you want the Adhesive plugin to work for you, I bet this will help…
My friend’s hosting service runs php as cgi (and I suspect yours does, too)… In the adhesive_admin_footer() function there’s a call to $_SERVER['SCRIPT_NAME'] which is fine on my site with php but not on hers with php-cgi. On her site you have to use $_SERVER['SCRIPT_URL'], and that won’t work on my site.
So I changed it to test both and it seems to work on both.
I changed line 159 to:
if((preg_match('|post.php|i', $_SERVER['SCRIPT_URL'])||preg_match('|post.php|i', $_SERVER['SCRIPT_NAME'])) && $_REQUEST['action'] == 'edit')
I hope this helps anyone else with the problem. It’s the old php as cgi catch!
Rich
Thank you so much for posting that change.
I had been going nuts trying to figure out why I wasn’t getting the sticky checkbox on my edit page.
I could add in a custom field named sticky and a value of 1 and the sticky post would be displayed as it should, but I could never get the checkbox to show up.
Now, it does. My host is running php as cgi.
Thank you again!
RichH,
You are a lifesaver! I’ve been trying to figure out why the heck Adhesive wasn’t working on one site (hosted somewhere where php is run as cgi) but on another it worked just fine… and now, after changing the code the way you suggested, I finally get the sticky box as well! Thanks so much.
Rich H,
I too have been trying to figure out the Adhesive problem for months. Don’t know why I missed your solution before, but I’m glad I finally found it.
Anyone else on Dreamhost should follow your advice.
Interesting situation: I’m NOT on Dreamhost, but a couple of my sites are on php-as-cgi servers. Adhesive on the blogs on those servers works just exactly as it should – and just as it does on blogs on my php-as-apache-module servers.
Wouldn’t it be lovely to discover just exactly WHAT the break-point really is? It can’t JUST be php-as-cgi….
