I actually had not been following the latest WordPress developments too closely, and so I was quite pleasantly surprised by what the upgrade to WordPress 3.3 offered in terms of looks and functionality. But…
There were a few things that I had some issues with. First, I absolutely hate that the toolbar is on by default and apparently can’t be turned off without losing some important functionality. The toolbar is my least favorite feature of all the newer WordPress features. It’s ugly and intrusive. Why are you guys so focused on pushing this thing? Is it because of WordPress.com? I get it’s usefulness in that context, perhaps, but with the WordPress.org implementation it gets in my way more often than not.
I create custom plugins for all of my WordPress installations with some custom functionality and admin modifications appropriate to their contexts. Apparently a few of those were sloppily built because as soon as I upgraded, they promptly broke. There was just one line I screwed up in regards to calling a function within a class (typo), but it was something I didn’t notice as I never really ran those plugins through rigorous testing.
One of my favorite plugins for modifying the administration screen is Dean Robinson’s Fluency Admin. Unfortunately the update seems to not be compatible with it. Not one to be deterred, I went about modifying the new admin css to look at least passingly like Fluency.
If you were interested in doing the same, you could run this code through your functions.php file in a pinch, or better yet add it in a plugin:
function like_fluency_css() {
echo '<style>
*,body {font-family: helvetica, sans-serif;}
img#header-logo{display: none;}
#adminmenu div.wp-menu-image {float: left;width: 1px;height: 28px;}
#adminmenu .wp-menu-image a{display: none;}
#wp-admin-bar-wp-logo{display: none;}
#adminmenuback, #adminmenuwrap {background-color: #222;border-color: #444;border-right-color: #ddd;}
#adminmenu li.wp-menu-separator {display: none;}
#adminmenu div.separator {border-color: #0e6ac8;}
#adminmenu a.menu-top, .folded #adminmenu li.menu-top, #adminmenu .wp-submenu .wp-submenu-head {border-top-color: #444;border-bottom-color: #000;}
#adminmenu a {color:#fff;}
#adminmenu .wp-submenu a {color:#777;}
#adminmenu a:hover, #adminmenu li.menu-top>a:focus, #adminmenu ul.wp-submenu a:hover {color: #fff;}
#adminmenu li.menu-top:hover>a, #adminmenu li.menu-top.focused>a, #adminmenu li.menu-top>a:focus {background-color: #000;text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.4);}
#adminmenu li.wp-not-current-submenu:hover>a {border-top-color: #000;border-bottom-color: #000;}
#adminmenu li.wp-not-current-submenu .wp-menu-arrow {border-top-color: #000;border-bottom-color: #000;background: #000;}
#adminmenu li.wp-not-current-submenu .wp-menu-arrow div {background: #000;border-color: #000;}
#collapse-menu {color: rgba(255,255,255,0.3);}
#collapse-menu:hover {color: rgba(255,255,255,1.0);}
#collapse-menu:hover #collapse-button {border-color: rgba(255,255,255,0.4);background-color: #333;background-image: -moz-linear-gradient(center bottom , #333, #444);}
#collapse-button {border-color: rgba(255,255,255,0.2);background-color: #000;background-image: -moz-linear-gradient(center bottom , #111, #000);}
#adminmenu .awaiting-mod, #adminmenu .update-plugins, #sidemenu a .update-plugins, #rightnow .reallynow {background-color: #464646;box-shadow: 0 1px 0 rgba(255, 255, 255, 0.5);color: #FFFFFF;}
.folded #adminmenu .wp-submenu-head {border-bottom-color: #ccc;border-top-color: #ccc;}
.folded #adminmenu li.wp-has-current-submenu, .folded #adminmenu li.current.menu-top {border-bottom-color: #6D6D6D;border-top-color: #808080;}
</style>';
}
add_action('admin_head', 'like_fluency_css'); //remove logo from admin
There will be more in the days to come, but for now, I’m happy with the progress the team continues to make, and thanks for a great, free product!
So, I got bored one day and decided that I wanted to make a weather widget for WordPress. Sort of. I thought that I needed one for a WordPress theme I was thinking about making. As per my previous experience, I couldn’t quite find one that fit the bill, and some were just downright cumbersome in implementation. A veritable nightmare.
When I first started development, I wasn’t too keen on what API/xml data feeds to use, so I went with the ever popular Weather.com XML data feed. Development was a bear because the terms of use were incredibly restrictive. You had to display their logo, which is fine, but then you HAD to display four links that were meant to generate click-throughs for them in some fashion; and all of this had to be visible near the weather data itself. Ok, I said to myself, I can deal with that, even if it makes the whole thing ugly.
This whole thing is kind of funny to me. But hey, you have to monetize that data.
Two weeks later, they decided to end the free XML data service in favor of a different API model. I thought, “Excellent, I can finally develop something free of the cumbersome links and logos I was required to use before!” Not so fast. This service cost several hundred dollars a year. Not so good for me if I’m creating a plugin. Then I discovered Yahoo! Weather, ironically enough, powered by Weather.com’s data.
Ok, get to it already, jerk.
Fine, fine, fine. I simply thought that background information would be useful for you. With the previous version of this plugin, the version using Weather’s data, you were required to register with Weather.com in order to obtain a key that would allow you to access the data, and I had to build that in to the plugin. This version will work fine without it. Yay! Simplification!
However, your site is limited in the number of requests that can be made in a given day. So if you have a high traffic site you’ll run into issues if you’re constantly requesting data from Yahoo. I had to build in data caching in order to keep those requests down, so now you’ll only access the API once or twice every hour to update data and that should take care of the problem. So, it’s not instant, but probably good enough.
At the moment this plugin is a little hit and miss. I don’t plan on doing much more with it, but feel free to fork this, modify it, whatever.
Download Current Weather 1.5 (current-weather.zip)
Download From the WordPress Repository
So, enjoy the fruits of my labor!
If you’re developing websites using WordPress as your CMS, you’ve probably had to decide whether or not to create a plugin for that site’s functionality or to just dump it into your theme’s functions.php file. My solution used to be the latter, but lately I’ve found the former to be superior for one simple reason: themes are less permanent and more likely to be changed after you’ve passed it off to the client than a plugin. Hell, even I change my theme frequently enough for it to be an issue.
That news is likely old hat to you, but it took me a while to really see things that way. I’m not much of a serious developer, and so I don’t have extensive training or knowledge of programming models and logic, but I’ve always had an interest in it. Unfortunately, using object oriented programming wasn’t something that I understood how to do. Don’t get me wrong, I get the model, and how useful it is, I just never knew how to implement it logically, efficiently, and usefully.
I found, though, that as WordPress progressed, it was going to become quite useful to understand OOP on at least a basic level.
As it stands, I’m becoming heavily invested in developing for WordPress, and when I create a site now, I am generally going to be modifying the user experience in such a way as to require the creation of a plugin. This is to make sure clients aren’t doing something that breaks the site, or to shut down some unneeded functionality mostly, but occasionally I’m adding some handy widgets and custom post types.
Bottom line: if you need some Theme dependent functionality, the obvious choice is to keep it in the functions.php file, otherwise create a plugin to preserve that functionality across themes.
I recently found myself needing a way to display the most recent posts from multiple custom post types in multiple widgetized areas of a site I was working on.
Because I needed to do this quickly, and I assumed this need was common, I was on the lookout for an already well written and developed plugin that would do the job. I ran across a widget plugin from New2WP that allowed you to display the most recent posts from a single custom post type. Unfortunately, it wasn’t a multi-widget and you could only select one post type, so the plugin wasn’t suitable.
This is a
fine plugin, it just needs to be multi-widget capable to be more useful.
My first thought was that I could easily turn the plugin into a multi-widget capable plugin, but when I started to work on it, I realized that any modifications I made could easily be overwritten on the next update. Additionally, when I began work on turning it into a multi-widget plugin, it became exceedingly obvious that I would probably need to start from scratch.
That’s when I decided to develop a plugin of my own, based on the structure of what I saw in the plugin from New2WP, that would fit my needs, and hopefully the needs of others.
Where to Begin
Visit the
Widgets API reference at the WordPress codex for a better overview of this information.
Once I figured out that I needed to turn the widget into one that could be used in multiple widgetized areas, I started to research like mad to find out what it would take to accomplish this. One trip over to the WordPress codex was enough to send me in the right direction.
It was basically as simple as this default usage code implies:
class My_Widget extends WP_Widget {
function My_Widget() {
// widget actual processes
}
function form($instance) {
// outputs the options form on admin
}
function update($new_instance, $old_instance) {
// processes widget options to be saved
}
function widget($args, $instance) {
// outputs the content of the widget
}
}
register_widget('My_Widget');
However, converting the existing plugin to this wasn’t as simple as the above code implies. The old plugin was built as a function, and its structure made it quite a bit more difficult to tie into the WordPress Widgets API.
Based on what I learned from New2WP’s plugin, and the WordPress Codex, I proceeded to build out my own plugin.
The Recent Custom Posts Plugin
I started by creating the directory /mm-recent-cpt/, the file mm-recent-cpt.php, and readme.txt file for future upload to the WordPress plugin directory.
In the php file I added the plugin header:
/**
* Plugin Name: Recent Custom Posts
* Plugin URI: http://mikemattner.com/custom-post-type-widget/
* Description: Multi-widget for displaying recent posts of custom post types.
* Version: 1.0
* Author: Mike Mattner
* Author URI: http://www.mikemattner.com/
* Tags: custom post types, post types, latest posts, sidebar widget, plugin
* License: GPL
*/
This allows WordPress to gather information about your plugin. If you just put that file into the plugins directory right now, you’ll have a plugin that does nothing, but it will show up in the list.
The structure of this widget is fairly simple because of the Widgets API. You’ll create a class that extends the WP_Widget class, essentially making it a breeze to create this plugin. I named my class mm_recent_posts. In order to get things moving, you need to initialize the plugin. In most cases you’ll use add_action to get your class or function working.
The function I’m calling with add_action returns register_widget, which takes the $widget_class argument. According to the Codex, $widget_class is the name of a class that extends WP_Widget.
So, this is my basic structure:
add_action( 'widgets_init', 'init_mm_recent_posts' );
function init_mm_recent_posts() { return register_widget('mm_recent_posts'); }
class mm_recent_posts extends WP_Widget {
/** constructor */
function mm_recent_posts() {
parent::WP_Widget( 'widget_recent_cpt', $name = 'Recent Custom Posts' );
}
function widget($args, $instance) {
// outputs the content of the widget
}
function update($new_instance, $old_instance) {
// processes widget options to be saved
}
function form($instance) {
// outputs the options form on admin
}
}
The above is fairly self-explanatory as far as what each function’s purpose is. The constructor function mm_recent_posts() is designed to give a little information about the widget. You could use something along these lines to get it up and running: parent::WP_Widget('my_widget_base', 'My Widget title', array('description' => 'Very simple widget example', 'class' => 'my-widget-class'));.
Pretty easy, right?
The Plugin
The plugin I created is fairly straightforward. It is essentially just an extension of the original Recent Posts widget that comes with WordPress by default–except that this doesn’t overwrite that.
If this looks like something you could use, feel free to download, use, and modify till you’re blue in the face.
Download Recent Custom Posts Plugin 1.0.1 (recent-custom-posts.1.0.1.zip)
Download From WordPress Plugin Directory
I’ve now uploaded the plugin to the WordPress
plugin directory. I hope you’ll find it to be useful.
I’m working on getting this added to the WordPress plugin repository The plugin can also be downloaded from the WordPress plugin repository. If you have any questions, comments, or modifications, let me know in the comments. I can’t guarantee that this will work with all plugins, particularly the Custom Post Type UI plugin, but I will say that I’ve used it, and it works for me. I apologize if my code isn’t up to snuff.
Also, welcome Stumblers! Thanks for stopping by. Hopefully you’ll find my little plugin to be useful.
WordPress finds new ways to amaze me; some of these things are neither impressive nor particularly noteworthy, except that these things enable users to customize this platform in ways unimaginable to regular Joe Blogger, who simply uses the system. And in spite of how common such things are to those who truly dive into it, I struggled for quite a while trying to find the best way to change a bit of core functionality.
Note: I want to caution you to avoid doing anything with WordPress’ core functions if you aren’t familiar with php. You will regret it, especially if you’ve done something directly to a core file. Stick with filtering and extending with plugins.
If you scroll down to the bottom of the site on the home page, and on any entry page, you’ll notice a set of buttons that will help you navigate to the next and previous entries, or the next and previous pages of the home page. I needed a way to style these, and oddly enough WordPress did not provide a class name for either of those links. Too bad. So I needed to find out how to adjust that in order to target those links. In addition to that, I needed to also make a small change that classes wouldn’t have allowed for, which was to get the function to output code for the cases in which there were no other pages or posts in a given direction. My first thought was to find whatever core file these functions were located in and then make the change there; I proceeded to do this, got it working, and decided that I should go about this in a different way if I ever wanted to upgrade without having to change that file every time–if I even remembered in those instances.
The tags in question were: next_posts_link, previous_posts_link, next_post_link, and previous_post_link, as well as a few more functions that were related to them. Each of these provides the basic functionality I needed to modify; I tried to replicate these functions, using the same name, in an effort to essentially overwrite the original WordPress core functions. Well, I located them in the link-template.php file, copied and pasted them into my themes functions.php file, and proceeded to make the necessary changes. When I uploaded functions.php and refreshed my site, I had a big giant error; actually it was less an error and more a blank screen, which is worse in a lot of ways as you have no idea what went wrong. I should have known from my programming experience that I couldn’t duplicate these functions in this way.
I was stumped for the longest time, and search after search on Google was leading me towards something called, add_filter, which it turns out doesn’t quite overwrite the function so much as filter the function results through your new function; this was not what I wanted to do on any level. I couldn’t manipulate the data through a filter to achieve the needed results.
After some time, and a lot of searching, I landed on a WordPress MU forum (still not sure what MU is), that gave me my answer–the most obvious answer–which was to take the functions I needed and rename them. I could then use those new function names in place of the old ones wherever I needed them in my theme files.
That’s easy, ain’t it? Why don’t people explain this more often, or even need to to do this enough for it to be found on Google?
Update 1/19/2010: I wanted to clarify just in case some one stumbled upon this looking for an actual bit of code that might show them what I was up to. So here goes.
Instead of adding a filter to the function you want to change:
add_filter('next_posts_link', 'new_next_posts_link', 0);
Add a new function to functions.php and call it in your template wherever you were going to use the old one.
function new_get_next_posts_link( $label = 'Next Page »', $max_page = 0 ) {
global $paged, $wp_query;
if ( !$max_page ) {
$max_page = $wp_query->max_num_pages;
}
if ( !$paged )
$paged = 1;
$nextpage = intval($paged) + 1;
if ( !is_single() ) {
if( empty($paged) || $nextpage <= $max_page) {
$attr = apply_filters( 'next_posts_link_attributes', '' );
return '<a href="' . next_posts( $max_page, false ) . "\" class=\"next\" $attr>". preg_replace('/&([^#])(?![a-z]{1,8};)/', '&$1', $label) .'</a>';
} else {
$attr = apply_filters( 'next_posts_link_attributes', '' );
return '<span '.$attr.'>'. preg_replace('/&([^#])(?![a-z]{1,8};)/', '&$1', $label) .'</span>';
}
}
}
function new_next_posts_link( $label = 'Next Page »', $max_page = 0 ) {
echo new_get_next_posts_link( $label, $max_page );
}
I’ve essentially adjusted this line:
if ( !is_single() && ( empty($paged) || $nextpage <= $max_page) ) {
$attr = apply_filters( 'next_posts_link_attributes', '' );
return '<a href="' . next_posts( $max_page, false ) . "\" $attr>". preg_replace('/&([^#])(?![a-z]{1,8};)/', '&$1', $label) .'</a>';
}
And changed it to this next bit in order to add a class to the link for styling purposes as well as to display a grayed out link if there was no next (or previous in the case of those set of functions) page.
if ( !is_single() ) {
if( empty($paged) || $nextpage <= $max_page) {
$attr = apply_filters( 'next_posts_link_attributes', '' );
return '<a href="' . next_posts( $max_page, false ) . "\" class=\"next\" $attr>". preg_replace('/&([^#])(?![a-z]{1,8};)/', '&$1', $label) .'</a>';
} else {
$attr = apply_filters( 'next_posts_link_attributes', '' );
return '<span '.$attr.'>'. preg_replace('/&([^#])(?![a-z]{1,8};)/', '&$1', $label) .'</span>';
}
}
So, again. If you’ve got something to modify, do it this way. The functions.php template file is your best friend.
I’ve spent a little bit of time over the past few days (don’t worry, I’m still working on your wordpress template!) creating a brand new category of entries: articles. Articles are those longer entries that I really just want to add a bit of style to, something that breaks the regular layout, or something that I found I wanted to do but was limited by the entry layout.
You won’t see these too often, but when you do, they should be decent. You can identify them by the § icon next to them.
On another note, while getting my hands dirty messing around with the article format, and simultaneously reading about a brand new exploit to WordPress (no relevance I hope), my admin section started to act a bit funky. I decided that I needed to upgrade in order to save the damn thing. It worked, and I’m now fully upgraded to the latest version.
I made the mistake of turning off the pesky upgrade notification, because I thought, hey, I just got this version, it works, why bother? Don’t do that. Just upgrade when the next version updates.
I’ve noticed an inordinate amount of spam comments coming in over the lines lately; most from a user name like Free-I-Phones-and-how-to-get-them. They are not immediately published, of course, but they still come through.
If anyone works with WordPress and knows of an excellent spam prevention plug in, let me know.
I am currently in the process of upgrading my website. All over. From the portfolio, to the tumble-log-like blog. What prompted this most recent redesign? Well, on top of never being happy with one’s own work, I was particularly unhappy with the blandness of the previous design, plus…Wordpress.
I discovered the joys of using WordPress. I always felt like I had to hack through MovableType’s templating system, but with this I could actually build something using php. That’s something I can appreciate a great deal.
At this moment, however, I am manually transferring all of the links, quotes, and entries that I can. It is a LONG process. And of course one that is next to impossible to accomplish. I cannot simply import all of my old entries, although that seems to be what I need to do, because when I did so, it was not too successful. I may give it a try again, but it’s going to take some time to get it done right. Time that I have I suppose.
Oh well.
I’ve been working on a bit of a personal project lately and decided the easiest and best way to introduce a blog would be to install WordPress, plus I really wanted to give that system a little more of a try than I had in the past.
My gut reaction upon installing and settling on a theme for modification was that this was REALLY easy to work with and highly customizable. I had, in fact, gotten used to working with my own MovableType installation, its quirks, and its own templating system, but the php based WordPress on my server was a breeze to deal with compared to the former. It was faster, offered better plugins, easier templating, and I could even edit the hell out of those plugins to customize the installation even further for my needs.
I’m so convinced by my experience that WordPress is the superior publishing platform for anyone looking to get started beyond the free services and put up a site on their own domain, that I am absolutely going to develop the next iteration of this site with WordPress in mind.
MovableType has been good to me, and it truly is a very powerful platform, but my servers don’t deal with it, and it is SLOW as a result. Plus, all of the plugins I want to use aren’t offered for MT or don’t offer what I need. And that can be frustrating.
What I like about MT, though, is the publishing experience. I feel like I can easily add tags to any entry with little problem, and the interface (MT 4.0+ at least) is minimal and easy to use. Previous versions were a bear to work with, I’m afraid, but 4.0+ is quite fantastic.
Anyway, my conclusion: WordPress for the future iteration, but MT will suffice for now; WordPress is superior to MT for beginners and its ease of use; and MT is not likely to catch up.
Update: 5/15/09 I am currently in the process of converting to WordPress. Manually. Really frustrating, but worthwhile. I’ve also discovered that it is a superior publishing experience.
← →
