In the better late than never category: notes about plugins from core team meetup in December! http://make.wordpress.org/plugins/2012/08/18/93/
Tagged: plugins Toggle Comment Threads | Keyboard Shortcuts
-
Jen Mylo
-
Andrew Ozz
A bunch of unused images were removed from core in changeset 21498. Several of them were background gradients that were replaced with CSS 3 gradients. The rest have been unused in core for few releases.
However there are some plugins that use a few of these images and would need updating. Best thing to do would be to copy the images locally as that makes a plugin independent from core changes. If the images were gradients, best would be to use CSS 3 gradients (example).
-
Emil Uzelac
-
Dominik Schilling (ocean90)
Hey Emil,
the -ms- prefix for gradients is no longer necessary for the final IE 10, see http://blogs.msdn.com/b/ie/archive/2012/06/25/unprefixed-css3-gradients-in-ie10.aspx.
MS filters are ugly, but there is a ticket for it: #19233
-
Andrew Ozz
By the time WordPress 3.5 is released (December 5) IE10 would be out (October 26) and as Dominik said it supports the standard CSS3 gradients.
The core ticket is about adding CSS gradients support for older IE (7, 8, 9).
-
Emil Uzelac
Thanks guys
Emil
-
-
-
-
Andrew Nacin
On Saturday, Matt posted to the WordPress Blog that the plugin directory has been refreshed.
Also also posted to our new P2 at make.wordpress.org/plugins: what this means for developers. @otto42, @coffee2code, and I go through the changes in detail. They include:
- The new Developers and Support tabs for plugins
- Subscribing to commit emails (Hint: see the Developers tab)
- Following and managing support threads
- How the new support statics are calculated
(Sidebar: We hope to use make.wordpress.org/plugins for announcements and resources for plugin developers. This blog will also move to make.wordpress.org soon. More to come.)
-
Julien
By the way (not sure whether there’s a better place to say this), wordpress.org seems to have been broken for the last week or so, on Chrome/MacOS: http://cl.ly/2Z0f3P2F091V2C0T0127
Cheers
-
arena94130
May be 3.4 schedule needs some refresh : http://wpdevel.wordpress.com/version-3-4-project-schedule/
-
Andrew Nacin
Plugin committers now receive svn notify emails with every commit to their plugin. This is something we’ve been planning to do to assist with collaboration, but we added it today without extra things like being able to sign up for other plugins. (Look for that soon, though.)
And not to sound like the PA in a subway or at an airport, but if you see something, say something. Say things to security@wordpress.org.
-
Christopher
Andrew, I noticed this today while updating a plugin, it’s a great added feature! Thanks.
-
Denis
Any plans to switch the plugin repo to git at some point?
-
Peter Westwood
Nope
-
Ramoonus
-
Denis
There actually is a much better intake here: http://teleogistic.net/2011/05/revisiting-git-github-and-the-wordpress-org-plugin-repository/ – but it would still be quite neat if, instead of svn, WP was using git in the first place.
-
Andrew Nacin
We wouldn’t move the plugins directory to git without moving everything to git, and there are no plans to do that.
-
-
-
arena
I appreciate this
But :mails sent are only html (plaintext not supported)
i don’t know how they look like in other mail readers but in gmail they look ugly (most of the css is discarded).-
Alex M.
i don’t know how they look like in other mail readers but in gmail they look ugly
http://daryl.learnhouston.com/2011/06/01/legible-svn-diffs-in-gmail/
-
-
Brian Layman
I got my first one of these yesterday. These are really slick! they look great!
-
-
Andrew Nacin
Commit access has been restored for plugins. If you get a 403 error, you need to go reset your password. Please, to something new.
-
mitcho (Michael 芳貴 Erlewine)
Thanks to all who worked tirelessly to keep us safe!
-
-
Samuel Wood (Otto)
It was pointed out to me that I never mentioned it anywhere when I made this change last month, but the plugin search engine at http://wordpress.org/extend/plugins/ has been much improved. So now when you search for things like “buddypress”, you should get what you’re looking for on the first page of results more often.
It was a minor adjustment, so it didn’t occur to me to tell anybody. Sorry about that.
-
Valentinas
Well try to search for ad-minister. Other search strings to test: wp-e-commerce, wp-ad-manager, basically anything that has wp prefix will produce the same search results. And you know there’s plenty of plugins with that prefix.
-
Otto
The search engine treats dashes as search operators. Meaning foo-bar searches for items containg foo but NOT bar.
Leave out the dashes when searching, for now.
-
Jane Wells
Maybe drop a text instruction to that effect on the plugins search page? People search for wp e-commerce all the time.
-
Otto
Jane: I was planning on just fixing it so it didn’t do that, actually. Nacin’s idea was the same one I was planning on implementing.
-
Otto
Done. Hyphens now get escaped properly for the search when they don’t have spaces around them. So “e-commerce” will actually search for that as a word instead of considering it to be a control character. You can still use a hyphen in front of a word for exclusion, as long as it doesn’t have some other word character in front of the hyphen.
-
-
Andrew Nacin
We can probably make it convert hyphens into spaces if the hyphen isn’t preceded by a space. I’ll check it out.
-
-
Bill Erickson
When I search for Contact Form 7, the plugin shows up on the second page, even though I search for its exact name. This has been bugging me for about a month
-
Otto
Yep. But, that’s a pretty generic title too. I didn’t say it was perfect, just better.
-
Jane Wells
Actually, I think it used to come up as one of the first results, so for that one it looks like a loss. There are a couple I can’t find by searching now. What was changed to the search/what’s it searching now? If there are things we can do to the plugin metadata or readme files or whatever to make them more findable with the new search, we can publicize it.
-
Otto
Basically, I added extra weighting to the title, gave the tags a bit more weight, and turned on the “extended” matching mode, which makes it actually use the weights. Before it was in a simple text-only keyword search mode, which didn’t use any relevance or closeness matching at all.
The thing is that “Contact Form” is a fairly generic name, and while it does give the title a lot of boosting, every single one of the results on the first two pages has “Contact Form” in its title.
-
Sergey Biryukov
Perhaps if there’s an exact match, it can go first?
-
-
Valentinas
Yes, I wanted suggest the same as Sergey, exact match should definitely be the first.
-
Otto
Well, that’s not the easiest thing to do in the world. The question is what do you define as an exact match?
The Sphinx search engine works based on phrase matching. Now, in the particular case of “Contact Form 7″, the 7 is pretty much being ignored because it’s too short. So we’re really talking about “Contact Form” here. Note that it doesn’t much matter even if we were talking about the full “Contact Form 7″ because several of the other plugins above it also have “Contact Form 7″ in their titles as well.
And that’s the trick. The whole thing is based on a weighting algorithim. I gave titles a lot of weight specifically in order to push title matches up to the top, but in this case, all the ones that show up in the top 20 results have “Contact Form” in their titles. Several of them have “Contact Form 7″ in their titles as well, because they’re addons to it or what have you. So how is the search really supposed to know that “Contact Form 7″ is more important than “Contact Form 7 Addon”? Sphinx doesn’t give extra weight to “whole” titles.
I also give a bit of extra weight to tags, which is probably why some of those are coming up a bit higher than others. The relevance scores are all pretty close right there.
Basically, doing exact whole-phrase matches in Sphinx is kind of a hacky PITA, involving adding extra data to the database using delimiters for before and after and such. I’d prefer to get the 90% solution where people are searching for keywords and titles and having it get close-enough rather than adding a ton of extra data just to cover that one particular case. Especially when the case involves a really generic title like “Contact Form”.
So Protip for code authors: Come up with a unique name to be listed higher in searches. This is not specific to our search engine.
-
Matt
We’re not really discussing matching, but ranking. I think it’s fair to, given the results that Sphinx returns, re-order based on a metric like popularity or bump exact match (search == title) to the top.
-
Otto
Popularity ordering is already there if somebody wants to use it: http://wordpress.org/extend/plugins/search.php?q=Contact+Form+7&sort=popular
-
Matt
I guess it’s odd to me that popularity and rating are not part of relevance — if you think outside of the strict-matching sense of relevance, they’re all really one and the same. Whichever provides the best results to the most people should just be the default.
-
Otto
Ordering by rating is already there too: http://wordpress.org/extend/plugins/search.php?q=Contact+Form+7&sort=top-rated
But I find the other side of this odd, really. It doesn’t make a whole lot of sense to me that popularity and rating have anything to do with relevance. Relevance is really more a measure of how well the plugin’s description/name/tags/whatever fits the keywords/phrase you’re searching for. In other words, relevance is about the plugin itself and your search query, not about user-generated meta data about the plugin like popularity or ratings.
Could we include rating and popularity as a metric? Probably, but I’d have to investigate Sphinx in more depth. Those fields are not stored in the Sphinx database right now for sure, so it can’t include them in the relevance matching algorithm.
-
Otto
Scratch that, they are in there (rating and downloads over the last week), so they can be used. I’ll do some testing, see if it makes any difference.
-
Matt
I don’t think most people think of relevance that way. The core bug is you type in the name of one of the top ten most used plugins in the world and it doesn’t come up in the first page.
Type “akismet” and Akismet is #5.
Type “stats” and you see a page with 2 results, and 40 pages. (The counting/paging bug mentioned.)
My goal is to not give people multiple ranking options for the plugin search, just to have one that always gives you the results you’re looking for.
-
Otto
Yes, but everything is a tradeoff. At what cost do we bump more popular plugins? The cost is that less popular, but possibly better or more useful, plugins get bumped down.
Moving exact whole-title matches to the top is one thing (technically tricky, actually, but doable), but counting popularity and rating in seems different to me.
-
Andy Skelton
Stats and Akismet are good test cases. Almost any plugin can legitimately use the word “stats” in its description and many could reference Akismet, but a title including such words indicates extreme relevance. Titles are always more relevant than descriptions.
-
Otto
This is the problem with generic phrases. “stats” has 591 results over 74 pages, and the first several dozen (at least) have the word “stats” in their titles.
I’m doing more testing/tweaking to it now.
-
Otto
Also, the title of the plugin is actually “WordPress.com Stats”, so an exact matching check wouldn’t help it out there for “stats” anyway. Slugs are not included in the search system at all.
-
Otto
Still looking at how to bump an exact title match to the top (this requires bypassing the search engine results to make it work), but after looking at the weights, I can at least tell you some specifics of why you see the results you see.
Akismet is 5th because the other 4 above it include “Akismet” as a tag. So they get bumped for that.
WordPress.com Stats: Same problem. The ones above it have tags with “stats” in them.
-
Andy Skelton
WordPress.com Stats has “stats” as a tag.
-
Valentinas
Some thought on why akismet should be first:
Download count (maybe take into account how many copies were downloaded recently). So up to 10.000 downloads – 0%, 10k-100k: 0.1%, 100k-1m: 1%, 1M-10M: 10% and so on..
Vote count (probably the same as download count, just different numbers, 100 votes – 1%, 500 votes – 10% and so on)
Vote value (only take into account if has 50 or more votes): 1 star: -10%,2: -5%, 3: 0%, 4: +5%, 5L +10%.compactability (also only take into account if 10 or more votes)….
and so on..
I think these properties are good way to tell if the plugin is good or not. So by combining them with relevance you should be able to get good results. Of course this kind of stuff requires fine tuning..As Matt mentioned, you should test the search engine with top plugins. also do you have analytics running on plugins directory? would be a good idea to look at what keywords brings people to certain plugins and test with them.
-
Peter Westwood
To me the preferences for sorting would be:
1. Exact Match in Title
2. Order by install count / rating – download count is meaningless to me as it is too easily affected by having 100s of plugins release versions for minor buglets -
jb510
Thinking a little outside the box, Otto is right each search category (rel, new, upd, pop, rating) is there, but what I really want is the ability to combine those types of search. I want the radio buttons to be check boxes so I can search for “relevance” AND “popularity”.
Also, I wonder if you couldn’t add the abilty to search for exact name matches by entering the plugin name in quotes, ie. “Contact Form 7″?
-
Valentinas
jb510, that would be useful for advanced user, but what i’d like to have is something like Google (I think we can agree, that Google is an example of good search
). You don’t have any “popularity” or “relevance” or anything in Google, all you do is enter the name ( like before mentioned “contact form 7″) and you get the result. Google sells their search engine ( http://www.google.com/enterprise/search/mini.html ), but that may be not an option for WP, since it’s quite expensive (starts from $3000).Other than that idea about ability to search for exact name sounds pretty good (maybe even with a fallback to regular search informing the user about that – “we couldn’t find exact match for your query, but here’s some similar results”).
-
Otto
Exact name/slug matches (or fairly close) now get bumped to the top of search results.
In doing this, I discovered a case where results can be duplicated as well. it’s been there a while, but nobody noticed. That will take more time to figure out how to clean up.
-
Otto
Duplicate search results removed. These were rare, but they’re gone now.
-
-
-
Rich Pedley
either the number of search results is still incorrect, or we are missing page links.
-
Otto
The page links code was slightly off. It didn’t have the correct number set for its “per_page” count, so it had the wrong number of pages. I’ve corrected it.
-
Rich Pedley
nope still broke. search for eshop:
Showing 1-6 of 10 plugins with 6 displayed
page shows 9-9 of 10 plugins , and only 1 displayedand why 6 per page, seems a weird amount.
-
Rich Pedley
sorry that should have been page 2 shows 9-9etc
-
Otto
I don’t know what you’re seeing, but for “eshop” it shows me 1-8 out of 10, with 2 pages. Works properly.
-
Otto
Ahh, okay, actually you’re seeing different results because you are not an admin who can see the hidden plugins. Basically those are plugins that have been entered and approved but which no code has been uploaded for them yet. So they are getting removed from your display, but not from the total count.
I’ll look closer at fixing that. But the normal display is 8 per page. If you see less, then the search is finding “unfinished” plugins then hiding them.
-
Rich Pedley
Yeah that would explain it – but won’t help others
Majority of people searching are not admins.and even so, 8 per page seems weird, can’t you bump it to 10? or is there some reason that octal rather than decimal is being used? Or even better a drop down selection to show 10/25/50 per page.
-
Rich Pedley
a search for directorypress is returning this in the results:
http://wordpress.org/extend/plugins/directorypress/
but that plugin no longer exists, so I’m guessing it got removed. But it’s still being found when searching. -
Otto
Fixed. Numbers for searches are still going to be a bit off though. Working on it.
-
-
-
-
Samuel Wood (Otto)
New for Extend/Plugins:
If a user clicks the “Broken” link, it will record the click as usual, but now also redirect them to the start a new topic support form, and nicely ask them to leave a new topic explaining what’s broken. Hopefully, this will make the broken button more useful.
Note: if you want to test this, feel free, but realize that you’re marking the plugin as broken by doing so, whether you leave a new topic or not. So please, go back afterwards and change your vote to “works” if it really does work.
-
Ipstenu
Sweet!
-
Ofer Wald
How about doing the same for the dreaded single star vote?
-
Denis
Is there an RSS feed that plugin authors can use to grab all of these forum threads? If not, it would be even more useful… Especially if advertised.
-
Otto
Every forum thread made via this manner gets tagged with the plugin’s slug. So you can subscribe to a plugin’s topic list that way.
Example: http://wordpress.org/tags/simple-facebook-connect has an RSS feed on it of http://wordpress.org/support/rss/tags/simple-facebook-connect .
Email notification hopefully coming soon.
-
hakre
Feedburner offers Email Integration for RSS.
-
Denis
That’s not good enough. It’s fine when you’ve a plugin or two. But when you’ve dozens, it becomes a lot of feeds to track.
Moreover, these tags point to multitudes of support requests that are related to WP bugs and incompatibilities introduced by third party plugins — stuff that I don’t even want to be reading.
What’s needed are two unified feeds. The first should lead plugin devs to all open threads related to his plugins, regardless of tags. The second should lead plugin devs to the subset of these threads that were opened by the broken button.
Using tags for any of these two feeds is not an option unless the community spirit and attitude have improved dramatically. When I was answering support requests in the WP forums, the tag I was using got dropped in a hostile effort to move it out of the hot tags page.
-
Otto
Better ways of notification are coming as well. Email notification is next on my list, followed by handling tags better.
One step at a time, man.
-
Denis
Personally, I don’t read emails any more than Knuth:
http://www-cs-faculty.stanford.edu/~knuth/email.html
I do subscribe to RSS feeds, however. So if anything, that works better.
-
Otto
It’s a combo deal. Emails come first, because though I use RSS and agree with you, the majority want the emails. Emailing an existing feed is simpler than emailing a non-existent one.
-
Matt
Denis, I’m sorry it’s not good enough. it’s better than before. And it’s being worked on.
-
-
-
Chip Bennett
Next step: change the vote not to record until a new forum topic is posted.
(Either way, very cool stuff, Otto!)
-
Rich Pedley
oh yes that would be nice. Then add automatic changing of vote to works once thread is marked resolved… Oh sorry I think I just saw a cuckoo in the clouds.
-
-
hakre
Yeah, nice! I’ll play a bit with it and let you know
-
Denis
Adding to my last comment… Isn’t there a risk that end users report plugins as broken when they run into a WP bug or some incompatibilities introduced by their theme or other plugins?
-
Pross
Maybe the author should verify its broken?
-
Devin Reams
Are you really suggesting that doesn’t already happen?
-
Otto
They were doing that already. Now they have a chance to report the problem.
Ignoring their vote because they refuse to explain it would be rather unfair. The number of people who think it doesn’t work is valid data, regardless of why they think that. This isn’t ebay, where one negative means nobody trusts it.
-
Denis
I believe you’re misunderstanding the question. On occasion, users report things as broken when it really isn’t. For instance:
http://wordpress.org/extend/plugins/sem-admin-menu/
One reports CSS is loaded, always. Which is an enhancement at best…
The next is an incompatibility with another plugin…
-
Otto
No, I understand just fine. However, if they’re reporting it broken, then that’s between you and them. What, we’re supposed to make somebody jump through hoops or make it harder or something?
-
-
-
scribu
some info from the readme is missing: http://core.trac.wordpress.org/ticket/14719
-
Otto
Not a bug, Matt told me to remove them.
-
Ipstenu
Otto, would that be why some authors don’t show up on their plugins? I don’t seem to be listed as an author on any of my plugins, and that …. Well, makes it hard for people to know how to get in touch with me for support
-
Otto
Ipstenu: No, this was because your plugin didn’t have your correct wp.org username in the Contributors: line in the readme.txt. Caps count there too.
I’ve just modified this to show those author listings correctly. Although, if it can’t find you as a valid user, you get no gravatar and no link (because there’s nothing in profiles to link to). This will at least prevent the link weirdness we once had on the authors listing.
-
Stephen Cronin
As a plugin author, the more links to my site the better!
But that’s not important. What’s important is this:
As a user, I’ve found that *most* plugins have extra information, comments, etc on the plugin home page on the authors site. The removed link to the plugin home page is something I clicked a lot.
I take Matt’s argument that this link can be added to the content area, but a) the vast majority of plugins aren’t going to have this and b) those that does will have it in a slightly different location.
End result, instead of having a *consistent place* on *all* plugin pages where I can easily find this link, I have to search for it and in many cases it won’t even be there. There’s a term for that sort of thing:
Usability fail
The link to the author’s site is less important, but the link to the plugin’s homepage (on the author’s site) should remain (in my opinion) – because that makes the site more usable for the users.
-
-
scribu
An explanation would be nice. Spamming can’t be a valid reason, since you can insert links directly into the description.
-
Otto
Dunno. You’ll have to ask him. Anyway, I don’t think the design there is final yet, so they may make a comeback. We’ve basically just been playing with it, to see what looks and works better. Eventually I hope to have some useful stats for authors as well, for example.
Bringing any of this up on trac is probably premature. Email me directly if you have concerns, I read them all and respond to most. otto at ottodestruct.com
-
Denis
I fail to see any incentive to write a free plugin if you don’t even get some web traffic as a result.
-
Alex M.
If that’s the only reason you’re writing plugins, then I feel sorry for you Denis.
-
Otto
I gotta say that I think those links drive very little traffic. Matt said at #wcsav that I remember (because we used my plugin to do it), that something like 20% of his ma.tt traffic now comes from his facebook links (which are auto-published by SFC). There’s better ways to drive traffic back to you. Developing is generally done to fill a need, not to drive traffic.
-
scribu
As a counter-example, about 20% of my referrall trafic (10% overall) come from wp.org
-
Otto
If it’s that big a deal, put your links in the description of the plugin. You can put links there, you know.
-
Matt
Plugin links are a little redundant now that each plugin has a page on the directory. If someone has a page on their own site as well easy (and more effective) to link from the main content area.
Author links only work for single-author plugins, for multiple author plugins (which we want to encourage) it’s broken so better to build it off the commit list, so each author gets credit.
-
Alphawolf
Well, if it remains like this, we have a useless profile field “Website URL ” then:
(which funnily enough sais “Give yourself some link love.”
)It’s useless if the website URI neither shows up on the profile pages nor on the plugin pages anymore.
On a side note, the wp.org repository would be the only plugin repository I know that doesn’t link back to the dev’s website at least. Personally I found some really nice blogs worth subscribing through the plugin pages (such as Viper’s, Ozh’ etc.).
-
Matt
Our goal is to drive even more back to plugin authors than we do now, but give some time for the iterations to finish up.
-
scribu
Thanks for the explanation Matt. Makes sense now.
Michael H. asks to move the author info back to the top:
-
Matt
That’s nice, but not really useful at this stage. If you have something you really want on that page maybe just send me an email.
-
-
scribu
Speaking of developer site links, I think we can all agree that it makes sense to show them on profiles.wordpress.org (they were there, but vanished at some point)
-
Matt
Definitely — not sure what’s up with those pages. The URLs are wrong too.
-
-
filosofo
With profiles.wordpress.org being pushed into greater prominence, can we either fix or remove the activity stream? For example, it shows my last core trac activity as having occurred in March.
I will volunteer to make the fix.
-
Rich Pedley
Have to agree with this, it’s been like that for months.
-
-
-
John James Jacoby
Nice work Otto! Like the changes so far and know it will only improve as you iterate.
-
Otto
Thanks! I think a lot of people aren’t getting the “iteration” concept here.
-
Alphawolf
I’m sure you are aware already, but just for the sake of completeness, the short description above the tabbed navigation doesn’t convert Markdown currently. But that’s just a minor minor issue that came to my eyes.
-
Otto
The short description should be text only. Markdown is not allowed there.
-
Alphawolf
Sorry, my fault then.
-
-
-
-
Samuel Wood (Otto)
Gravatars are now shown on the plugin listing page. It’s a minor thing, but people like pictures and clicking on pictures. Clicking on somebody’s picture will take you to their plugin profile, showing all their plugins.
-
Michael Torbert
Awesome!
-
Glenn
Nice touch!
-
Andrea_R
Very very way cool.
On multiple-author plugins, are the gravatars supposed to be stuck together, or do you think they’d look better with a wee bit o’ padding?
-
Otto
I stuck ‘em together intentionally cause I liked the way it looked, but I’m open to suggestion on layout there if somebody has a better one.
-
Andrea_R
(I liked them stuck too.)
-
-
-
Ipstenu
padding 1px
-
Rich Pedley
Wouldn’t it make sense to add the gravatar to this page as well: http://wordpress.org/extend/plugins/profile/ ?
-
Rich Pedley
oh and you messed up something somewhere, there appears to be spurious or missing tags.
-
Rich Pedley
that should have been: spurious <strong> or </strong> missing rags.
(my oops) -
Otto
Fixed.
-
Rich Pedley
looks a lot better now, thanks Otto.
-
-
-
Rich Pedley
and on my final note, will it be added for themes as well…
apologies for my poor speeling today, one of those days again.
-
kyleabaker
I think you should add something like this to the avatars:
border: 1px solid #999;
padding: 1px;It looks great like this with 4 avatars per line, but the text-indent is forcing 3 per line on every row after the first. If you could get these to all line up correctly then it would look great!
-
Alex M.
Is the second line of Gravatars supposed to be indented?
-
Alex M.
It’s due to the other items having the same indent if they’re too long (minimum version and such).
We can probably remove that indent I think from the Gravatars.
-
Otto
Yeah, you’re probably right. What do you think, remove indent and squish, or remove indent and give some padding. As long as I’m changing the CSS, might as well get it right the first time.
-
kyleabaker
I say remove indent and add padding. Its much easier to control and looks much better with all of the rows of avatars lining up properly.
-
Alex M.
Personally I think remove the indent and add a slight padding. It doesn’t need to be much, just enough to separate them IMO.
-
Alex M.
Or maybe as much padding as there is between rows (so it becomes a grid). I mean we have all that space to the right…
-
kyleabaker
This would be my take on the design..
-
kyleabaker
Looks like html image tags aren’t allowed
-
Alex M.
Here you go, kyleabaker:
-
-
-
Utkarsh Kukreti
I’d suggest adding authors name as the title attribute of the link, so the name shows up on mouse hover.
-
Otto
I can’t believe I didn’t think of that. Done. Also styled.
-
Alex M.
Looks great!
-
Utkarsh Kukreti
How about ” ()” instead of just the username?
-
-
-
Ron
Saw this earlier today. Love it.
-
hakre
the sidebar get’s crowded. Maybe placing into main content under authors?
-
Otto
Some other changes are coming to the sidebar soon, actually, so it won’t be as bad.
-
-
Matt
I expected the gravs to be smaller, and inline with the “Authors:” list.
-
Otto
What, just like a tiny picture on the left of each name in the list? Seems like that’d look strange to me. Easily changed though.
-
-
Otto
After some review and such, this whole thing is getting changed much more extensively. Expect gradual updates over the next day or two.
-
Alex M.
A link to the plugin’s homepage is missing.
-
James
Are there any plans to bring back to “Plugin URL” and “Author URL” links that used to be near the top right of the page?
Thanks -
Otto
James: No. If you want to link back to your homepage, add the link into your description area. The markdown for links looks like this: [http://example.com](link text).
-
-
-
w3prodigy
Not sure if this is a bug, or you guys doing your thing – (going based off of my plugins) if a plugin does not have a readme file then no author name shows up
-
Rich Pedley
If the plugin doesn’t have a readme, why is it there? I thought it was a requirement for the plugins to have a readme?
-
Jay Fortner
“To make your entry in the plugin browser most useful, each plugin should have a readme file” – I always took “most useful” as a recommendation to create a readme file, not a requirement.
Since the plugins would still function without a readme, I generally don’t create the readme file until my plugin reaches a stable version – this is a better development cycle for me… clearly though, if the plugin directory is changing and now explicitly requiring a readme to display properly, I’ll add it. I was simply noting the differences between the previous way the plugin directory functioned and how it functioned after the recent changes.
-
Otto
Several things probably have to be clarified but:
a) Readme’s are not really optional. All plugins must have a readme.txt.
b) The Contributors line in the readme should contain a list of the authors, using wp.org usernames only.This is how it’s going to be. If you give it bad input, you’ll get bad output.
-
Jay Fortner
Thanks for the clarification Otto, looks like I have some readme’s to write.
-
Otto
It’s been pointed out that I should clarify the above.
A plugin will go into the repo just fine without a readme.txt file. However, without the readme, then several pieces of the plugin’s webpage won’t display. The authors (contributors) is one of these pieces. So is the description and everything else. That listing in the plugins page is built mainly off the readme.txt file.
So while’s it optional in practice, it really should be there. The plugins/about page makes it a point to say that you should upload your plugin with a readme.txt file.
-
Otto
@Jay:
I’ve noticed that a lot of people aren’t putting valid author info in the readme file (they should be wp.org usernames, but many are not), so there’s a change I’m working on for that.Still, you should have a readme. It’s not needed for WP, but it is really needed for a good plugin page entry.
-
-
-
Otto
Like I said, after my conversation with matt and the upgrades, lots of things are changing. Gimme a day before suggestions, because what you see now is temporary.
-
Rich Pedley
I’ll make a list…
-
-
-
Aaron Jorbin
Plugin Developer Handbook Chapter List
Thank you to everyone that commented and help me brainstorm what is needed for a good plugin developer handbook. I’ve synthesized that information and have come up with the following chapter list / section plan behind the jump. Please let me know if there is anything you think I missed. Remember, this handbook is designed specifically for the task of Plugin development. It’s not designed to be the end all, be all guide to WordPress. It’s designed to help new plugin developers get to the point that they can build a plugin and assist existing plugin developers with finding the best practices for doing things.
The next step is going to be to find authors for all of these sections. I’m going to be reaching out to a number of people to help out, but I’d also love to see some people volunteer. Please contact me @aaronjorbin on twitter or jorbin in IRC if you think you might be interested in writing a chapter or section. I’m going to be leaning on many of you, the experienced core developers and plugin developers.
-
Stefano Petroni
Can’t wait to read it!
Thank you! -
Jane Wells
It would be great for volunteer authors to leave a comment on this post rather than using twitter etc. so that we can keep a record here.
-
Alex M.
I assume you’ll want me to take oEmbed? If no one else steps up, I can also document some other APIs such as shortcodes, transients, or caching. My freetime is limited though, so don’t heap too much on me.
-
Aaron Jorbin
Alex, You were just the man I had in mind for oEmbed. I don’t want to over burden you, but may come back and ask for help on another after I’ve talked to a few others.
-
-
peterchester
This is great! We’ve been working on bits and pieces of something like this at our company (Shane & Peter, Inc.) with the intent of ensuring that we all abide by the same coding conventions.
Is the idea behind this that developers would read the whole thing start to finish or that they would read a couple intro parts and use the rest of it as a look up index?
-
Aaron Jorbin
Section 1 is largely going to go over basics and outside of the introduction, should be skippable/skimmable by experienced developers.
Section 2 will hopefully be read by everyone. Section 3, pretty much the same though skimmable if you’re not storing any data.
Section 4 will largely be a reference section.
Section 5 will be used mostly for people releasing plugins publicly…which should be all plugin developers
-
-
mercime
Hi Aaron, perhaps in tips or dev section, add list of tools/arsenals to create a plugin. like basic text editor, poEdit, FF with Firebug and Web Dev extensions, etc. Or maybe that’s too basic?
-
Aaron Jorbin
That’s a bit more basic then I was aiming for, but I think that it will in part be up to the Authors.
-
-
Jacob Santos
Well, I could probably write the entire 5th section if you need a draft.
-
Aaron Jorbin
I’m going to Ping you in IRC one of these days. I think that at least one of the parts of Section 5 will be right up your alley.
-
-
Aaron Jorbin
One Additional Section I forgot to add (Section 6 or maybe Appendix A) will be a list of tips, tricks, and notes from a wide variety of developers. That will be assembled and worked on much later.
-
John P. Bloch
I’ve got WP_Rewrite like we discussed.
-
Stephanie Leary
I wrote a basic walkthrough of SVN for people who’ve never used SVN before as part of the plugin chapter in my WP book. It has a ton of screenshots using Versions for Mac and Tortoise for Windows. If it would be helpful, you can have it.
I think I also have the How to Get Help chunk.
-
Brian Layman
I’m up for the Short Codes entry if you need someone. Or one of the two other sections we’d discussed if needed…
-
Jay Fortner
If you need anyone for Actions and Filters or Coding Standards – I’m here.
-
Marjorie Roswell
Could this be placed on a wiki, so that names could appear next to the actual chapters? Might make it easier to see what’s left to claim.
-
-
Aaron Jorbin
Plugin Developer Handbook Planning
I’ve started brainstorming ideas for the plugin developer handbook and have come up with a pretty long list of topics that I think should be covered. Some of these will be chapters on their own, some will be combined together and others still need to be thought of. For right now, the best feedback you could give me is to tell me what I missed and what you think might be out of scope.
A couple of notes:
- I tried to include chapters so that both novice and experienced developers will be able use it. Hence ideas such as knowing the difference between the different languages used in WordPress.
- Some things, while listed, I think will include warnings and language that discourages it. The two that stand out to me are: Custom database tables and Custom Option Pages.
Alright, now for the list:
- Introduction
- Languages of WP – Differences between PHP, HTML, CSS, JS
- WP Coding Standards
- Organizing plugin files
- Planning your plugin
- Name Spacing
- Adding Styles and Scripts
- Actions / Filters
- How to use them
- How to add them to your theme so other plugins can use them
- Shortcodes
- Widgets
- Front End Forms
- Ajax
- Front end ajax
- Back End ajax
- Roles and Capabilities and users
- Custom caps
- User Meta
- Comments
- Comment Meta
- interacting with comment filters
- Options
- Adding options to existing admin pages
- Adding your own pages
- transients
- Translating / Internationalization
- Custom Taxonomies
- Custom Post Types
- Scheduled events (pseudo-cron)
- Activation / Removal hooks
- Interacting with the database
- Adding Tables / interacting with them
- Security
- Kses
- Escaping
- Capabilities check
- Nonces – Props Eric
- Interacting with remote URLs
- atom / rss
- Interacting with WP_Query
- Media
- Media and Post relations (Send to editor)
- Modifying / Creating URLs
- MultiSite specific Compatibility
- General Tips / Tricks / Notes (Ideally a tip or two from many different devs)
- Adding Admin Notices
- Giving your plugin the WordPress look (Hopefully the style guide will be finished before then).
- Pluggable Functions
- Admin Meta Boxes
- Dashboard Widgets
- Extending Tiny MCE
- A Good Development Environment
- Development Process
-
Mike Schinkel
Wow, that’s an incredibly good list. Kudos.
I think that to improve that list will probably take just working on it to realize what’s missing but otherwise it’s incredible.
-
Rahul Bansal
Such a handbook will be a real treat for plugin developers.
Being in business, I keep hearing from developers that wordpress codex is too primitive and wordpress lacks documentation a CMS need to win enterprise userbase.
I guess such handbook can fill that void. -
Eric Marden
I’d also cover functions.php. While a theme file, the techniques are largely the same.
-
Aaron Jorbin
I think the eventual Theme dev handbook will cover that more (and will share alot of chapters/sections with this handbook)
-
Eric Marden
I think its a topic worth touching on in Plugin Dev Handbook, but covering fully in Theme Handbook.
-
Aaron Jorbin
How do you think it should be covered? What in do you think plugin devs need to know about theme functions.php files?
-
Mike Schinkel
For one, functions.php is a great place to start testing out proof-of-concept functionality that may be later moved into a proper plugin. Discussing that and the process of moving from proof of concept testing to actual plugin might be helpful.
-
Aaron Jorbin
I’ve added a section on development enviorment that could probobly cover that unless there is something else I am missing?
I think I’m also going to add a Development Process section.
-
Mike Schinkel
Good idea. Elaborating, it would be nice to talk about setting up a local development environment on at least Windows, Mac OS X and generic Linux.
-
Eric Marden
I’d say that it should probably cover:
- The differences between functions.php and plugin files.
- What’s available and not available to you in functions.php
- When you should use it instead of a plugin
Then point folks to the theme dev hand book.
-
Aaron Jorbin
Eric – I think the first and the third parts would be good, I think the second is straying a bit too much into theme development and might be out of scope. This is designed to be one in a series of handbooks with the focus specifically on Plugin development. While a lot of the information within this handbook will also be in the theme developer handbook, I’d prefer it not confuse the two too much.
Mike – That’s exactly what I meant by setting up a development environment. I imagine that section is going to be heavy on links and lighter on content though.
-
Eric Marden
Aaron – Sounds good to me. As long as their some mention of it, and pointers to more, I think it will help people avoid confusion and concur that you get into theme land pretty quickly when using the functions.php bridge.
Mike – I agree with Aaron here, Dev Environment, while useful, is a bit out of scope. Pointing people to some good links is best, but this topic, I feel, should only be touched on in the scope of why its a good idea, not how to make it happen.
-
Mike Schinkel
@Eric: While not completely disagreeing I will say that the biggest “hump” I had to get over before I could finally be productive was getting a dev environment set up (I had been on Windows+ASP+IIS+SQL Server for 10+ years so LAMP/WAMP/MAMP was all foreign to me.) After I finally was able to get help getting it all set up (3+ years ago, for Drupal at the time) I was rapidly able to gain relevant skills because each step was such a small step from the one before compare with the initial setup. I’ve also taught a lot of people WordPress over the past 2 years (~100 people) in workshop environments and the most important step for almost all of them is getting the development environment set up. So given how little one can do without it compared to with it and given how big a hurdle it can be to set up I would suggest we at least consider giving it more weight than we might otherwise give it if it were not such a critical path to productivity. JMTCW.
-
Eric Marden
@Mike
While I don’t disagree that a local development environment is a huge boon to productivity and is an important topic, it starts to delve into the area of systems administration – one of the reasons I feel that a lot of new developers struggle with it, avoid it, or don’t even know they should or could have a local server. What I’m suggesting is limiting the topic to just the essentials and letting other sources deal with all of the other variables.
In other words, it could look something like this:
- Here’s WAMP (windows)
- Here’s MAMP (mac)
- Here’s apt-get (linux)
- Here’s how to configure a VHOST to serve one WP site.
As soon as we try to help them worry about multiple virtual hosts, the specifics of configuring Apache, managing the /etc/hosts file for overriding DNS this topic soon becomes unwieldy and given that it is not essential for you to have one to develop a plugin we shouldn’t try to create even a shadow of a full blown HOWTO on the topic.
Trust me, I’m the guy who has stepped in on a project and wouldn’t write a single line of code until the entire team got a local dev environment installed. But if there’s one thing I know about this topic is that getting the perfect set-up is almost impossible and the way they other guy did it is always “wrong”. Do I hand compile or use a package manager? Install binary components myself and tie them together in the configuration? A virtual machine with ubuntu? Or use a prepackaged all-in-one solution? Even the level of choice in this area, as you can see, can be overwhelming on its own and we haven’t even begun to tell you which steps to follow.
Another reason to err on the side of simplicity (and letting other sources guide the users more deeply) is that anything put in this handbook will end up generating questions on the forums, #wordpress and wp-hackers and shouldn’t we really be in the business of supporting WordPress and not their (particular) local server?
My 2 cents,
~e
-
Mike Schinkel
@Eric Fair points.
One thing that I would personally like to see is it be _comprehensive; that would have helped me so much 2 years ago and I’d like to see others not have to go thru the same. If topics are collectively deemed as being too much of whatever then I’d argue at least that we cover the topic by curating a list of articles and solutions even if they point off WordPress.org. Then, for example, we could find a multiple VHOST article that covers concerns related to WordPress or if one can’t be found then one of us could write one on our blog and link to it. FWIW multiplier VHOSTs were one of the more difficult things to figure out yet one of the ones I cannot image being without today. Ironically it was really not difficult, I just had to learn a few arcane details. those details would make a great article.
As for the other comment you made let me relate a story and I apologize that it is off topic for the develop handbook. Shortly after graduating college, probably 1992 I attended a presentation to entrepreneurs where the message hit home and has stuck with me for my adult like. In a nutshell the person made the point that if you have something you are “selling” (in our case we are all advocating for WordPress) then it is in your win best interest to make sure the prospective customer has as easy a time being able to acquire and use your solution as possible. If there is anything that would cause prospects to stall and go elsewhere, or simply not “purchase” at all then it is incumbent upon you to handle that problem for them or at least make the problem appear to go away.
So yes one can argue that we want to support WordPress only and not help people with their server setups and from a standpoint of purity you would be right. OTOH if we in fact do care about seeing a lot more people adopt WordPress then such perspective may be self-defeating. Note that the solution may not always be to “brute force” it but instead may be to divide and conquer (i.e. maybe we solve the problem by working with web hosts to minimize the problems, educate prospective users on which hosts have the least problems and then provide support for the remaining.) JMTCW.
-
Tim
Discussion of Dev Environments, to some degree, would be good. Rather than focusing on specific environments, maybe a better way to approach this section in the handbook would be to encourage standardized ways of reporting what versions of WordPress (version number and single vs. Multi-Site testing), PHP and MySQL a plugin has been tested on. Right now, there’s a “tested up to” tag in the plugin header, but there isn’t a consistent way to report PHP/MySQL version requirements.
Or perhaps this belongs in a new section covering “Writing a good readme file”?
-
Matt
Small handbooks, loosely joined.
-
Aaron Jorbin
Anything more then a passing reference is going to be too much. I don’t want this devolving into a 800 page coffee table book that no one actually reads.. It’s for WordPress Plugin Development, not system administration. Perhaps there will be another book focused on that.
-
-
-
Eric Marden
Also don’t forget to talk about nonces. Probably under security and/or options pages.
-
Aaron Jorbin
Thanks I knew I would miss something.
-
-
Denis
I think you’re missing an important bit: the WP flow, with an outline of the hooks and when they occur, in what order, what they’re used for, etc. And most importantly, how to not interfere with other plugins on the same hook… (eg never call remove_action(myhook, myfunc) on myhook.)
-
Aaron Jorbin
I think the API reference is going to more so cover flow. The actions section will definitely cover proper use of actions and priority.
-
-
Eric Marden
Media probably covers this a bit, but overriding the javascript send_to_editor was a recent find of mine and is worth covering. I’m guessing there are other Javascript ‘hooks’ (timymce stuff?).
-
Eric Marden
err… tinymce
-
Aaron Jorbin
Thanks. Good catches. Please, keep them coming.
-
-
Aaron Jorbin
Added:
Pluggable Functions
Admin Meta Boxes
Dashboard Widgets
A Good Development Environment-
Eric Marden
- PHP Docblocks
- Licensing and Distribution
- Promoting your Plugin
- Best Practices with JS/CSS (like not using !important in your CSS, etc)
- PHP Best Practices ( i.e. Coding with E_ALL on, avoiding common Notices/Warnings)
- SVN
- Releasing your Plugin on WP.org
- ReadMe.txt and plugin comment header
- Data Import/Export
- Migrations (WP_RELOCATE)
Obviously we’re getting into the minutiae now, and some of this stuff can be and probably is implied by some of what’s above, but thought I’d offer them up anyway. Also some of this may be running into other hand book territory.
Is this going to be collaboratively written, and if so where and on what platform?
-
Aaron Jorbin
I’m not sure if migrations would really fall under the purview of a plugin developer. I think that might fit better for a WordPress administrator book.
For Import/Export, I assume you mean import/export of plugin data. Correct?
-
Ryan McCue
Apologies for the off-topic reply, but what precisely is WP_RELOCATE? I can’t find a reference to it anywhere in code, and there’s only one reference to it on wp-hackers.
-
Eric Marden
Ryan – sorry its RELOCATE, documented here: http://codex.wordpress.org/Changing_The_Site_URL#Relocate_method
Aaron – You may be right. I continue to suggest things from a more holistic WP Developer mind set. Maybe we need a handbook that integrates admin, theme, and plugin from a top down approach, where these topics so far have been a bit more ground up. (small component effecting larger whole).
-
-
Mike Schinkel
Floating an idea. This could turn out to be a killer book if packaged as such, and might catch interest if available at major bookstores from people who might not otherwise dig into the topic. What about coordinating with a major publisher where the proceeds go to the WordPress Foundation? Again, just an idea to consider.
-
Matt
We can cross that bridge when we get there. I wish all of the WP books thus far had been under an OS license but most authors aren’t going to have that sort of leverage with their publisher. I had one tell me “books are hard, why would we allow anyone to take the content!” Yes, ma’am, software is hard too.
Now we’re completely off-topic, but here’s a link everyone should read:
-
Mike Schinkel
Yep, the idea is definitely premature but I figured it would be better to have in the back of our minds if doing so was an option. FWIW.
-
Stephen R
There’s an SVN book that is… not sure if it’s open source but they givve it away for free on the web site, or you can buy the physical book from O’Reilly. S not totally without precedent in books.
-
-
-
mercime
Plugin which create table/s in DB to add Uninstall function
Cheers-
Aaron Jorbin
That is part of the reason that people will be encouraged to use the existing data structures whenever feasible, but yes, that will be a part of custom tables.
-
-
João Pedro Pereira
Excelent list, Nothing to add besides TEST, TEST, TEST!
-
arena
Hi ! your list lacks structure.
Most of the topics are related to the numerous wp api’s
i would add the following topic
. admin (menus, admin pages, clean coding (not loading js or css if current admin page is not related to plugin))-
Aaron Jorbin
Actually it does have structure, it’s an unordered list with list items that sometimes contain unordered lists
For menus, I assume you are referring to interacting with the new nav menu items?
Clean coding will certainly be a part of the WP coding standards and proper use of wp_enqueue_script / style (i.e. adding it to the right hook) will definitely be a part of the adding styles and scripts section.
-
arena
i was refering to admin menus
-
-
-
filosofo
Who is the proposed audience, and what do you see as the niche for this document in a world of grep, googling, and the Codex? It would be good to determine that before investing too much time in the wrong topics or too many details.
Languages of WP – Differences between PHP, HTML, CSS, JS
I don’t know the exact intended audience, but if it’s “developers” by any reasonable definition it should exclude someone who doesn’t know the difference between PHP and JS. That person needs to be doing remedial programming–maybe read Master PHP in 24 Hours or whatever—first.
- Admin Meta Boxes
- Dashboard Widgets
- Extending Tiny MCE
I suspect that’s the kind of detail that won’t do any potential audience much good. If you’re at the place that you’re ready to extend TinyMCE, you’re just going to google how to do it. If you’re new to WordPress plugin development, being blasted by a firehose of details will probably impress upon you the potential of WP, but it’s unlikely most of those details will stick. Or worse, the wrong details will stick to the detriment of more important ones.
My suggestions: make the audience to comprise those with a reasonable knowledge of PHP, MySQL, and JS; neither beginners nor those who have an advanced knowledge of WP in particular. The former need more than you could possibly provide, and the latter don’t need your help.
And don’t think of it as an academic course, in which someone can dedicate a semester to studying every topic. That’s not how most developers with jobs learn. Instead, pick a few truly core concepts, the ones that are necessary and sufficient to getting a typical plugin running. Then you can let code examples hint at some of the other details: they will be enough to spark interest without making the reader feel unduly burdened.
-
Eric Marden
I think that this plugin should serve more than just beginners. Even a mention of what’s possible (by covering all of the various extension points in WP) and cross linking to the function reference in the Codex will be a huge help to all developers, beginners and advanced alike. I, for one, am a bit sick of having to grep the code base just to look up a function signature or having to trace the code to discover that there is an undocumented filter buried in the middle of one of the functions that get called – the exact filter I need to write my plugin cleanly. I kind of see this handbook as a part comprehensive overview and part getting started guide.
However, I do agree that a discussion on the difference between various languages and technologies used in the construction of a WP plugin is unwarranted and does provide a small barrier to entry for this part of the docs. Right now all the Codex has is this: “WARNING: Programming Code Ahead!” or something like that.
-
filosofo
I think that this plugin should serve more than just beginners. Even a mention of what’s possible (by covering all of the various extension points in WP) and cross linking to the function reference in the Codex will be a huge help to all developers, beginners and advanced alike.
Well, I guess it really depends on what the purpose of the handbook is supposed to be (its niche). To me what you’re describing sounds more like an annotated index of the Codex, or maybe even just the Codex already. That would seemingly be only a quantitative, not qualitative change from what’s already available.
-
Aaron Jorbin
@filosofo
I view this as being a compliment to the API reference, but more focussed on Narrative explanations and explaining full API sections. While the API reference will tell you that register_taxonomy is used to create or modify a taxonomy object, and what arguments it takes, the handbook will explain what you can do with that taxonomy after it’s created.Will someone like you, who has a deep knowledge of the code turn to the handbook first? Doubtful. I imagine you’ll find what you need in the code. Might you turn to it if you have never used the HTTP api and want to get an idea of some best practices and a understanding of how you can use that in concert with Simple pie? Perhaps. Will someone building there first through fourth plugin find it useful? Absolutely.
The reason I have the differences between languages is in part to help weed out the people that aren’t willing to learn more. I don’t view that as being as very long section. I imagine it being similar to http://aaron.jorb.in/blog/2010/01/you-better-know-the-basics/ , but better written. Then a simple: “Not scared to continue? Well onward to Victory!”
For some of the sections (like TinyMCE editor), I actually think it might be best to keep it simple and point them to a small handfull of plugins that are doing it so that they can read some actual code. That’s open for thought though
-
-
jeremyclarke
This looks great!
It’s a small detail, but It seems to me that the “Actions/Filters” section should come before “Adding Styles and Scripts”. As far as I know, adding styles/scripts is done through the API so knowing how the API works first is probably a good investment
I’m pretty sure you would have changed it during the writing but figured I’d mention it as an excuse to tell you the list looks great and I’m excited for the result
-
Aaron Jorbin
The order above was in no way meant to imply the order the chapter would actually come in. It’s more so the order I brainstormed them in.
-
-
Jacob Santos
It would be better to organize it in two or three sections.
- Plugin System
- How to Develop
- WordPress Library Guides
The Plugin System should include the introduction, what filters and actions are, how they work, how to add action and filters. Why and how they might be added to your themes and plugins.
How to develop section should include WordPress coding standards, Subversion, WordPress Extend, adding plugins, checking out, how to work with the support and Trac Ticketing. Could also include notes on PHP docblocks, unit testing, and general ui testing.
The WordPress Library Guides will include the large portion of the guide which would include every individual API section in WordPress and WordPress Admin.
-
Aaron Jorbin
My next step is actually to synthesize all this feedback and try to come up with a more coherent outline. What you’re proposing is pretty similiar to what I have in mind. Thanks Jacob!
-
bentrem
Are you setting up to co-author? Cuz I’ve been following DAV since *blush* a long time (see MozDawg on DAV and Docs, notes for which I started shortly after Netscape “released the code”.) Reason I ask: however slow the progress, progress there’s been. Now my first instinct was to shout out “This is a good start on a wiki page!” but I choked it back with something like, “Yaaa … yet.another dusty bit-rotted wiki page”.
Social dynamics.
Too bad GWave and GBuzz suck so completely when operationalized.
p.s. I got started Analogous Techniques next month but my “army of 1″ batteries are flat / dead. -
Stephen R
I think this is a really excellent idea. Part of the problem is making sure it will be updated over time and not grow stale == a problem oftentimes in Codex.
Something you might add: a section on “final polish” — little things like adding the “Setup” link from the Manage Plugins page straight to your settings page. There are lots of little useful touches that aren’t purely core function of the plugin, but just make it a lot nicer in the details.
-
Aaron Jorbin
That tip is one that I think would be perfect for the General Tips / Tricks / Notes section. At a later date and time I’ll solicit those.
-
-
Ramon Fincken
Nice!
Perhaps handy:
Scheduled events (pseudo-cron) + Ajax frontend > http://www.ramonfincken.com/permalink/topic187.html -
Mike Schinkel
I see you have transients (Transients API?[1]) but I don’t see any reference to the Settings API[2]?
[1] http://codex.wordpress.org/Transients_API
[2] http://codex.wordpress.org/Settings_API-
jeremyclarke
I think he just didn’t refer to it as the Settings API but he has:
Options
* Adding options to existing admin pages
* Adding your own pagesI think the first one would be the Settings API. Though its a good point that the section about adding settings pages should refer to the Settings API by name so that its brand is strengthened.
-
-
Byron
This Handbook is badly needed. It could seriously raise the average quality of WordPress plugins (my own could have benefitted tremendously when I start out a year-and-a-half ago). If it wasn’t for Vladimir Prelovac’s plugin book, I’d still be trying to start fire with sticks. Will this be open to contributors?
-
Jeff Sayre
Aaron -
Have you seen my article on WordPress action and filter events (hooks)? It could be useful for part of the information in the section on this subject. I have also created a plugin developers’ tool called the WordPress Hook Sniffer plugin. I just released an updated version this morning.
-
Marjorie Roswell
Some questions that come to mind: Where should we look for the handbook? Online? In print? When? Will the handbook be available in draft form as its being developed?
arena94130, 
Julien are discussing. 
Valentinas, and 8 others are discussing. 
Marjorie Roswell, 
Very nice!
Hey just out of the curiosity, is there a special reason why MS filters are not in CSS gradient, or is that because this is CSS3 only?
Example:
filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#fff, endColorstr=#000);
and maybe add
-ms-linear-gradient as well
Thanks,
Emil