undocumented WordPress.org Plugin API for plugin authors
Did you know you can get info about plugins in WordPress.org’s extend section in json or xml format? Virtually all the info about the plugin is available in machine readable format.
It’s as simple as adding the plugin’s stub name to the end of this url like so:
xml: http://api.wordpress.org/plugins/info/1.0/hello-dolly.xml
json: http://api.wordpress.org/plugins/info/1.0/hello-dolly.json
php serialize: http://api.wordpress.org/plugins/info/1.0/hello-dolly.php
You can request partial info or info on multiple plugins via the full API, which is not documented anywhere except this message from last year:
http://comox.textdrive.com/pipermail/wp-hackers/2009-January/023505.html
PHP code example:
http://wordpress.pastebin.com/raw.php?i=7Ji8rD2P
It was written by DD32 (aka Dion Hulse)
Missing from version 1.0 API are a few finer details like “downloads yesterday” & “last week” but that can always be derived from the graph data like so:
http://wordpress.org/extend/stats/plugin-xml.php?slug=hello-dolly
Graphing was just added to the bbPress.org side but the full API does not appear to be available (yet).
simple WordPress and bbPress security plugin to block long requests
I opened a WordPress security ticket today with something that’s been bothering me for awhile – Apache will take long URL queries up to 8k (8192) characters in length but it’s completely unnecessary and allows XSS exploits to get into WordPress and bbPress. Why not block them entirely with this scrap of a plugin (save as “_block_long_queries.php” without the quotes but with the leading underscore so it loads as early as possible and doesn’t need activation – also can’t be easily deactivated by hackers)
(more…)
Show Off Your WordPress Archives With Random Posts
I have a couple of blogs with posts now in the hundreds. Some of them are timeless articles, but often visitors won’t go digging that deep. So I started searching for a way to make a “Random” selection on the sidebar, under archives or categories so they could sample across the board.
After looking at half a dozen plugins to do this, I was fustrated that it was so messy. Once I picked one I thought I could live with, I found that I had to rewrite my template too extensively, changing the loop and it just didn’t feel like a good idea for the future.
Then after alot of Googling, I found this gem on the WP hackers list:
(more…)
new 2.1 menu privilege check breaks plugins?
Unless I am very much mistaken or have some kind of database issue, I have discovered some “new” code in WP 2.1 that breaks how many plugins add themselves to the admin menu.
I couldn’t understand after switching from 2.0.4 to 2.1 (a2) why some items were being hidden from me in the admin menu and then users at level 0 or 1 could not access other plugins they were specifically allowed to access (like gravatars and userextra) getting the error :
“You do not have sufficient permissions to access this page.”
(remember, it all worked correctly in 2.0.4, this is not the same issue as WP 1.5 users had upgrading to 2.0.x)
I finally traced it back to a change that was done between February 12th and 17th 2006
http://trac.wordpress.org/changeset/3536#file2
http://trac.wordpress.org/ticket/2257
by Ryan Boren
Something is wrong with the way he is searching and setting the menu access privileges that is breaking many plugins. I hope he can fix it so it is backwards compatible or there is going to be alot of confusion once the 2.1 beta comes out. It’s beyond my skills to figure it out without hours of work but if there is no answer soon I will do my best.
added: I’ve discovered that rolling back to the 2.0.4 menu.php and activating the “admin drop down menus” plugin will cause all menus to be available properly to both the admin and the subscribers – hiding what they are not supposed to be able to access. The code he uses may be superior to what WP uses by default. I do hope Ryan can figure it out and maintain backwards compatibility.
updated version of Text Control that works with WP 2.1-2.5
After struggling to get Text Control 2.0b1 to work with WordPress 2.1 even though other people are reporting it works fine, I found that someone had made entire code cleanups to Text control over here:
http://www.baptiste.us/2005/11/02/thoughts-on-xinha-text-control-and-wordpress/
Somewhere along the line, their cleanup made it work with 2.0 and 2.1 properly, even with all my other plugins.
That version still does not activate on WordPress “pages” (vs posts) so I had to hack in a couple of easy hooks…
update: here’s a fully patched copy of 2.0b3-mod,
ready to install to plugins (mirror just in case) (mirror 2)
(I’m posting these details below to show what changes are made)
in function tc_post_add_options() {
you have to add:
add_action('publish_page', 'tc_post_edit_post');
add_action('edit_page_form', 'tc_post_options');
What’s weird is it does not show the current formatting status auto-selected. I will have to hunt down that bug. But whatever you set it to, at least it obeys it.
I found the bug that was causing it not to show the current formatting settings for the post being edited. The way it’s grabbing the post ID # it no longer valid or not working (ie. $postdata->ID)
I changed it to this and it’s working fine:
function tc_post_options($content) {
$post_ID = (isset($_GET['post'])) ? intval($_GET['post']) : intval($_POST['post_ID']);
// Check if meta data already exists, otherwise use the defaults
$do_text = get_post_meta($post_ID, '_tc_post_format', true);
if (!$do_text) $do_text = get_option('tc_post_format');
$do_char = get_post_meta($post_ID, '_tc_post_encoding', true);
if (!$do_char) $do_char = get_option('tc_post_encoding');
One thing I REALLY don’t like about Text Control is it requires an extra database call for every post. I’d rather have some kind of internal WP code to disable formating, ie.
<!-- noformat -->
which would have zero database overhead and let you control the rest of the post natually.
Basically all I wanted this for was to be able to insert Javascript into a couple of my pages. What a workout, whew.
bug in paged comments plugin when using other queries, with solution
I found a minor bug in the paged comments plugin (last updated April 2006) when you are trying to use other queries on the URL.
ie. example.com/2006/07/25/text-example/comment-page-3/?test=1
will cause a 404, at least on my blogs
I traced it back to the function paged_comments_fancy_url() which doesn’t expect anything else on the URI except an ending slash or not.
To fix this just take the first line of that function and change it from
$req = rtrim($_SERVER['REQUEST_URI'], '/');
to
$req = rtrim(str_replace('?'.$_SERVER['QUERY_STRING'],'',$_SERVER['REQUEST_URI']), '/');
This is a quick fix solution and I am not certain what the effects might be since the function resets the request url back to $req later on. Other plugins might look direct at the url for the query string instead of at $_SERVER[‘QUERY_STRING’]
Not quite sure why he does it that way but my fix works so there you go.
paged comments enhancement – jump to calculated page for any requested comment
While I love the paged comment plugin (last updated April 2006) and consider it excellent coding, there is (at least) one or two problems with the way WordPress operates when comments are paged.
If comments are paged, WordPress should act more like a forum, ie. when someone posts a comment they should be returned to the last page where their new post appears, so they can see any posts afterwards, etc.
Additionally, if search enhancedments are used to include comments in searches, the resulting links should be able to take the searcher to the exact comment.
On paged comments, both these tasks are virtually impossible. Some people solve it by forcing paged comments to put the newest comments ON TOP of older comments. However this breaks the “forum style” of comment flow. Now you don’t have to resort to that behavior.
I’ve decided to tackle the first part of post-redirect to the new comment, first.
With flat “view all” comments because you just need to know the new comment id and you can hack wp-comments-post.php and just do something like this (at the very end):
$location = ( empty( $_POST['redirect_to'] ) ) ? get_permalink($comment_post_ID)."#comment-".$comment_id : $_POST['redirect_to'];
wp_redirect( $location );
Note the part in bold which is the only addition. Doing this as a hack is necessary because I don’t know how to hook that functionality otherwise (if you know how, please speak up). Inserting it as a hidden $_post “redirect_to” is not possible since the new comment_id does not exist yet and there may be additional comment posts happening as the visitor is viewing the very comments .(Why WP doesn’t have this simple addition as the default and just returns the visitor to the top of the post is a mystery to me, among many WP mysteries 😉 )
But making this work with paged-comments is extrodinarily tricky. I’ve tackled (for now) comments that are done in forum style, date assending order (oldest to newest) and do NOT fill the last page.
The code to add in wp-comments-post.php is listed below the break. It is tested but not for all situations or extensively. Any feedback/improvements are appreciated.
(more…)
measuring WordPress performance
At some point you might get curious about how fast or slow WordPress is actually running, especially after a few strange reports that 2.0.4 is running slower.
I had tinkered with Jerome’s Query Diagnostics plugin:
http://vapourtrails.ca/wp-plugins (at the bottom of the page)
but on the WordPress IRC I just learned about
libertus’ interesting “performance probe” plugin
http://libertini.net/libertus/wordpress-plugins/performance-probe/
which looks even more fascinating… (also see his other posts here and here)
added: apparently I can’t use his plugin (as many people on shared servers will discover) since my PHP was not compiled with the “–enable-memory-limit configuration option” – there is also a php function called “memory-get-peak-usage” which might be helpful to some.
Be sure to see all the links on the right hand side on my main page here for more performance and development plugins/info on WordPress.
By the way I made a subtle enhancement to Jerome’s output, the code follows below the break:
(more…)
nifty WordPress plugin saves search history
One of the (several) features that I miss from Movabletype on WordPress is that there was a search log.
Sure enough, today I stumbled across a nice plugin that keeps a very nice history in the control panel.
http://andersdrengen.dk/?p=129
http://andersdrengen.dk/projects/searchhistory/
Only thing I changed is that I made sure the userlevel was 9 or above and I like to keep the plugins and menus together so I changed this line to include the path and make a “searchhistory” folder:
add_management_page(__(“SearchHistory”), __(‘SearchHistory’), 1, ‘searchhistory/searchhist.php’)
Now if someone would just “beef-up” the WordPress search so the visitor actually has some control over what they search (not just hacks to search everything without options for the visitor). I’d even settle for the visitor just having the choice of searching comments or not via a checkbox.
login attempt limiter plugin for WordPress?
update: yay! I found exactly what I wanted in Owen Winkler‘s un-released “Armor” plugin:
http://comox.textdrive.com/pipermail/wp-hackers/2006-March/005290.html
limits the login attempts and emails the blog owner to let them know of the attempts…
really well written code too!
———
Someone on the WordPress IRC channel told me that there is a login attempt plugin that will limit how many times a user attempts to login? I can’t find any such creature? So if you know of where it’s hiding let me know before I attempt to code it tonight 😉
Also, apparently we are going to get a really nice plugin to ensure good passwords, really soon from the lushlab folks 🙂
_ck_ says... 