If you’re using the Simple Tags plugin, you might be holding off on upgrading to WordPress 2.9.1 because this plugin is only Compatible up to: 2.8.

Well, turns out the plugin does actually seem to work with WP 2.9.x — but you have to make a quick edit to the plugin file itself. Now, normally i’m not a fan of hacking plugin files to get things working because your changes would be lost with each new release. But, in this case, i figured that when the author does decide to release an update, i would be ok with losing these changes because they would no longer be necessary anyway.

Note: if you’re not comfortable editing plugin files directly (although this edit is really easy), then maybe you should wait until the author releases an official update. Otherwise, i’ve included the bit of code here for reference.

To get Simple Tags working with WP 2.9+

1) Open simple-tags.php and find the line:

if ( strpos($wp_version, '2.7') !== false || strpos($wp_version, '2.8') !== false ) {

2) Change that to:

if ( strpos($wp_version, '2.7') !== false || strpos($wp_version, '2.8') !== false || strpos($wp_version, '2.9') !== false ) {

That’s right, it’s just a matter of adding the additional condition which allows WP version 2.9 to work.

As always, be sure to backup and test this fix on your own site before going live.

This fix was found / documented here:
- http://www.wordpress-fr.net/support/viewtopic.php?pid=173448#p173448
- http://www.herewithme.fr/simple-tags-et-wordpress-2-8#comment-34072

Some notes:

Amazon Associate Filter – nothing happens

Amazon Book Picture from ASIN – just creates images from ASIN , uses shortcodes

Amazon Carousel(*) – flash, uses shortcodes, cool, lots of options, easy to use

Amazon Context Links Ads – does nothing

Amazon Machine Tags – complicated, uses shortcodes, requires an AWS key

Amazon MP3 Clips widget(*) – cool, flash 9.0.45 or above required, shortcodes, lots of options

Amazon Niche Store(*) – shortcodes, lots of options, 10% of the time is plugin author’s Amazon affiliate ID, plugin author linkback, widget included

Amazon Product Ads(*) – widget only, displays 1 item only, self-optimizing (auto) setting

Amazon Reloaded for WordPress – adds setting to post page but ajax not working

Amazon Search – not working, error: MissingParameter / Signature, widget and shortcode links only

Amazon Showcase – Access Identifiers required (AWS keys?)

AmazonSimpleAdmin – Access Identifiers required (AWS keys?)

Amazon SmartLinks Widget – many widget, working pretty well, looks nice

Amazon Widgets Shortcodes(*) – cool, lots of shortcodes, adds section to post page, conflicts with Amazon Niche Store plugin resulting in no output, must know exact widget ID

Keral Patel Amazon Wordpress Plugin – requires an amazon web services access key

(*) i liked, but needs further testing

Gigs Calendar (v0.4.6)
- issues with timestamps posted to the future (but not with filter turned on)
- no multi-day events
- post created automatically

GigPress (v1.4.9)
- lots of setting (maybe too many)

Events Manager (v2.0rc2)
- not creating “real” WP posts (with post IDs)
- all event posts are on same page (eg: domain.com/events?events_id=1)

Events Calendar (v6.5.2.1)
- simple / good
- fills in actual post content

Events (v2.1.1)
- not creating “real” WP posts (with post IDs)

Event Calendar (v3.1.4)
- just adds dates and times to the edit posts screen

Calendar (v1.2.2)
- buggy (widget seems broken)
- not creating “real” WP posts (with post IDs)

Keep in mind, i’ve only tested these specific versions of each plugin. So, newer versions might include significant improvements over previous versions. Also, don’t take my word for it.. test them all out for yourself ;)

ok, with the release of WordPress 2.8.3 – if finally got around to upgrading my Notify Admin Only plugin to work with WP 2.8+

Download Plugin: Notify Admin Only v2.0

in case you’re not sure what this plugin actually does, well, it removes this text from the backend that says: “A new version of WordPress is available! Please notify the site administrator” – (see the images below).

great for admins who don’t want their many users to ever see the WordPress Update nag.

anyway the new code is really simple: (thanks Lazzymonk)


< ?php
function stop_wpupdate() {
if ( current_user_can('manage_options') ) {
return;
} else {
remove_action( 'admin_notices', 'update_nag', 3 );
}
}
add_action( 'admin_notices', 'stop_wpupdate', 1 );
?>


the old plugin is here and only works for WP 2.3 – 2.5 series.

that was before the big upgrade of WP 2.5 -

that’s right, i’m sure many out there can remember the chaos that came with upgrading your WordPress blog beyond version 2.5. there was an entirely new backend to get used to, but there were also lots of small code changes that created compatibility issues in many plugins and themes. one of the major changes was the way WordPress was to handle cookies and authentication in general which was made to be more secure. as a result, coders were offered new methods of integrating logins but (at the time) there was little to no clear, accurate documentation detailing how to achieve this task.

i spent many hours last year (with WordPress 2.5 and 2.6), and then again earlier this year (with WordPress 2.7), and then again this weekend (with WordPress 2.8).. until i finally got it working with the help of a relatively new plugin and some new blog posts describing how others attempted this now seemingly daunting task.

anyway, i thought i’d share my notes as well as the steps i took to get this working with my setup. it’s currently being used on indyish.com to unify the various WordPress installs into one cohesive multi-user site.

Note: These steps assume you’ve already got your WordPress sites setup using a shared user database. So, you can log into any of your sites individually with the same credentials, see all the same users under “Users” > “Authors & Users” – but you want to get it so logging into one site automatically logs you into all of your sites.

Therefore, you have already added the following to the wp-config.php files for any of the sites other than the root site:


define('CUSTOM_USER_TABLE','wp_users'); // shared user db
define('CUSTOM_USER_META_TABLE','wp_usermeta'); // shared usermeta


1. To start with, you’re going to need to download and install this plugin: root Cookie Path. Make sure to activate the plugin on all of the sites (the root site, as well as any subdirectory sites).
2. Once all your sites are using a root cookie, you need to open up the wp-config.php files for any non-root sites (ie: subdirectory sites).
3. Now here’s the trickier part… go to your root site (ie: yourdomain.com) and get the following info from your Global Options page: AUTH_SALT and LOGGED_IN_SALT. You can find the Global Options page for your WordPress install at: http://www.yourdomain.com/wp-admin/options.php (replace “yourdomain” with your actual domain)
4. When you have these 2 values, you need to paste them into the wp-config.php files for every single non-root site you want to integrate. Use the following syntax:
   
define('AUTH_SALT', 'some-crazy-wacky-random-long-string-of-characters');
define('LOGGED_IN_SALT', 'some-crazy-wacky-random-long-string-of-characters');

5. Then, you need to make sure all of your sites are using the same “secret keys”. Paste that info into the wp-config.php files for each of the non-root sites you want to integrate. You can get secret keys fresh from the WordPress API page if you haven’t already added them to your wp-config.php file. It should look something like this.
   
define('AUTH_KEY', 'some-crazy-wacky-random-long-string-of-characters');
define('SECURE_AUTH_KEY', 'some-crazy-wacky-random-long-string-of-characters');
define('LOGGED_IN_KEY', 'some-crazy-wacky-random-long-string-of-characters');
define('NONCE_KEY', 'some-crazy-wacky-random-long-string-of-characters');

6. Finally, add this cookie information to the wp-config.php files for all your non-root sites:
   
   $baseurl = 'http://www.yourdomain.com'; // replace with the actual domain name for your root site
   $cookiehash = md5($baseurl);
   define('COOKIEHASH', $cookiehash);

   define ('AUTH_COOKIE', 'wordpress_'.COOKIEHASH);
define ('SECURE_AUTH_COOKIE', 'wordpress_sec_'.COOKIEHASH);
define ('LOGGED_IN_COOKIE','wordpress_logged_in_'.COOKIEHASH);
define ('TEST_COOKIE', 'wordpress_test_cookie');


That should do it!

Note: Some people have gone ahead and modified the WordPress capabilities.php file in order to get a role assigned to newly registered users, but this step is optional and requires editing a core WordPress file (a change which wouldn’t persist from one upgrade to another). I prefer to just assign a role manually to any new user that needs access to one of the non-root sites. Or, you could find another trigger to use before calling the function that sets the new role. Still, if you want to go as far as modifying core WP files, here is the code used by Kiran: (but i haven’t tried it personally)

function _init_caps() {
global $wpdb;
// $this->cap_key = $wpdb->prefix . ‘capabilities’; /* original code */
$this->cap_key = ‘wp_capabilities’; /*modified code */
$this->caps = &$this->{$this->cap_key};
if ( ! is_array( $this->caps ) )
$this->caps = array();
$this->get_role_caps();
}


Finally, here are some resources i used to help me out (most recently):

• Setting up a common login across multiple wordpress installations
• Setting single login across multiple Wordpress 2.7 installs using a single domain
• root Cookie Path 1.4 an Update for WordPress 2.7
• root Cookie Path

Here are some other sites (for reference) which i used earlier on this year:

• Installing two WordPress blogs with the same users
• HOWTO: Set up secret keys in WordPress 2.6+
• SSL and Cookies in WordPress 2.6
• Editing wp-config.php
• Installing Multiple Blogs

As far as i could tell, there are currently 2 other CC plugins for WordPress – wpLicense and cc-configurator – however both of them only let you set your license on a global level. That is, they let you pick one license for all your posts and pages throughout your entire site. I thought it might be useful if each WP user/author could choose between different CC licenses and be able to set them on a post-by-post basis. So, i modified the wpLicense plugin to do just that.

“The main purpose of this plugin is to give WP admins who run sites with multiple users/authors the option let these users/authors set specific CC licensing terms on a post by post basis.”

How it works:
It uses the CC api and the JsWidget to add a new section to the write/edit post page and then displays a small CC graphic/button and text on your published posts for all to see. The widget lets you choose the appropriate licensing structure and then your choice is automatically saved to a custom field the next time you click “Save and Continue Editing”, “Save”, or “Publish”. Then, it uses the CC api (details-license-uri-uri) to call some javascript that displays a small graphic/button and some text linking back to the definitions for the license you have chosen. Jquery was used to insert the new CC license section to the write/edit post pages as well as to open/close the new section. I also had to use Jquery to fix the tooltips for the JsWidget. Lastly, this plugin is optimized so that it will add only 1 DB query (the cc_js_result_uri) to each post that has set a CC license and stores it to a custom field for that given post – whereas the wpLicense plugin seemed to use 3 seperate db queries to set the global licencing for the site.

Screenshots:
Check out the plugin in action.

Download:
Click on the following link to download the plugin: per-post-license_v.02.zip

Requirements:
1. This plugin has been testing and works on WP 2.3.x using the default theme (but it is still a work in progess / comments and suggestions are welcome).
2. Your web server needs either curl (most have it installed and it’s the default setting used in this plugin) or URL file-access enabled (to be able to run file_get_contents() instead of curl).

Install:
1. Unzip and Copy the per-post-license folder to your plugins directiory and activate it.
2. Add the template function (see next paragraph) to where you’d like the CC image/button and text to appear on your post (this might be the single.php or footer.php template file).
3. Go to the Write post page or Edit an existing post.
4. Look for the new section marked “CC License” and click the small “plus” sign to open the section.
5. Select “A Creative Commons license” and choose the appropriate licensing structure.
6. Save the post and You’re Done!

WP Template Function:
Add the following function to the WP template file (like single.php, or footer.php) to get the CC license to appear on your post.

Template Options:
Right now, there are only 2 options that you can use with the cc_insert_html() template function.
1. The first is the $display variable. [$display=true ---> will show the CC license , $display=false will not]
2. The second is the $use_curl variable [default is set to --> $use_curl=true , if you explicitly set $use_curl=false the plugin will revert to the php function file_get_contents() which is not always enabled on all web servers]

CSS styles:
Here is a sample style you can use to center, add padding and margins, as well as a horizontal dashed separator (you can ofcourse use any style you like). You would add this code to your style.css file in your template directory.
#cc_code { text-align:center; font-size:11px; width:450px; margin-top:25px; padding-top:25px; border-top:1px dashed #ccc; }
You could also just use inline css and replace the < div id="cc_code" > and add these styles directly – something like < div style="text-align:center; font-size:11px;" >.

To Do:
- get rss/atom feeds showing CC license
- possibly add CC to header (if appropriate)
- option to set per author licensing (for all an author’s posts)
- option to set global default license for entire site
- option to turn off graphic/button and just show text
- option to choose/add an existing licensing structure (other than CC) by providing a URL
- create another template function to gather and list all posts with CC licensing (by title)

In the previously mentioned article we used WordPress version 2.3.1 as our initial vendor drop. The following procedure illustrates how to use svn merge to quickly upgrade WordPress core files from version 2.3.1 to version 2.3.2 – without losing your local changes – but could be used as a general outline for upgrading any version of WordPress provided you followed the steps discussed in Part 1. Note: Backup your files and database before attempting any of this. Also, although not strictly required, the following steps assume you have some kind of shell access (like ssh) and a command line subversion client (like svn).

Maintaining Vendor Branches -
To perform this upgrade, we check out a copy of our current vendor branch (which contains our WP 2.3.1 source code), and replace that code with the new WP 2.3.2 source code. So, we simply copy the new files on top of existing files and directories. The goal here is to make our current directory contain only the new WP 2.3.2 code, and to ensure that all that code is under version control. I use the svn export command to grab the WP 2.3.2 source code – but downloading and extracting the WP files manually works just as well.

1. Prepare Current and New Code

$ mkdir upgrade
$ cd upgrade
$ svn co http://svn.yourdomain.com/vendor/wordpress/current/
$ svn export http://svn.automattic.com/wordpress/tags/2.3.2/
…


2. Copy, Resolve Conflicts, and Commit Changes

$ cd current [optionally, delete all files but NOT folders / dont delete .svn folders]
$ cp -a ../2.3.2/* .
$ svn status
$ svn ci -m "commiting WP 2.3.2 vendor drop to current branch"
$ cd ../../
$ rm -rf upgrade
…


3. Tag the New Version
Our current branch now contains the new vendor drop. We tag the new version (in the same way we previously tagged the version 2.3.1 vendor drop – in Part 1)

$ svn copy http://svn.yourdomain.com/vendor/wordpress/current \
http://svn.yourdomain.com/vendor/wordpress/2.3.2 \
-m "tagging WordPress 2.3.2"
…


4. Merge the Differences and Commit Changes
Checkout a copy of your current project (from Part 1 – we used the folder: “newproject”). Merge the differences between the tag of the previous version (WP 2.3.1) and the new current version into our main development branch. Type svn status to see what files were modified and resolve any conflicts. Run svn add and svn delete commands where appropriate. Commit the changes and our local version of WP will now been completely upgraded without over-writing or deleting any existing modifications we may have previously made.

$ mkdir newproject
$ cd newproject
$ svn co http://svn.yourdomain.com/branches/newproject .
$ svn merge http://svn.yourdomain.com/vendor/wordpress/2.3.1 \
http://svn.yourdomain.com/vendor/wordpress/current .
$ svn status
$ svn ci -m 'merging WordPress 2.3.2 into the main branch'
…


That’s all there is to it!

And, best of all, every change made to your internal project code – including those made to WP core files – is now documented and tracked from within your own local version control system.

Note: Don’t forget to visit http://www.yourdomain.com/wp-admin/upgrade.php in your web browser once you’ve completed all of these steps to make sure any database upgrades get applied as well.

Scenario:
Let’s say you have an in-house web developement project that is built upon or otherwise dependent on the WordPress core files. This can be for something as simple as creating/customizing your own WP themes and plugins, or as complex as maintaining your own modified versions of WP core files, with additional components/modules, etc. The important thing is that you imagine a scenario where you are already using Subversion to commit changes/updates to this internal project of yours. However, a problem occurs whenever a new version of WordPress is released. You need to upgrade the WP core files whithout losing any of the custom modifications you’ve been making up until now. Ideally, you would like to apply (to your internal project) only the changes made to the upgraded WP core files without over-writing any of your own work.

Solution:

“The solution to this problem is to use vendor branches. A vendor branch is a directory tree in your own version control system that contains information provided by a third-party entity, or vendor. Each version of the vendor’s data that you decide to absorb into your project is called a vendor drop.” (quote)

So, in this case, the third-party entity or vendor, is WordPress. What we want to do is: absorb the WP code into our own project. The rest of this article is going to illustrate the concept of “vendor drops” as they would apply to this particular scenario and using WordPress as the third-party vendor. Some of the benefits of this method are described in the article that the previously mentioned quote came from. In addition, this article goes on to describe the exact same process (but in more general terms) in a section entitled: General Vendor Branch Management Procedure. Well, here is my “Specific Vendor Branch Management Procedure” for WordPress.

Vendor Branch Management – Description

“Managing vendor branches generally works like this. You create a top-level directory (such as /vendor) to hold the vendor branches. Then you import the third party code into a subdirectory of that top-level directory. You then copy that subdirectory into your main development branch (for example, /trunk) at the appropriate location. You always make your local changes in the main development branch. With each new release of the code you are tracking you bring it into the vendor branch and merge the changes into /trunk, resolving whatever conflicts occur between your local changes and the upstream changes.” (quote)

Our Setup -
Let’s use WordPress 2.3.1 as an example. A newer version of WP (2.3.2) was just released and we’ll be using that version in a follow-up article to show how you can maintain this setup across multiple WP version upgrades without losing your local changes. However, for right now, we’ll assume that this is your first vendor drop and that your current project is already using Subversion and is also built against WP 2.3.1. In theory, you could use this same procedure with any version of WP – just make sure to start with an initial vendor drop that is the exact same version of WP as the one your project is currently using. Remember, we are not upgrading WP yet. We are just importing the WP code into our existing subversion-based system, side-by-side with our internal project. Note: Backup your files and database before attempting any of this. Also, although not strictly required, the following steps assume you have some kind of shell access (like ssh) and a command line subversion client (like svn).

Creating Vendor Branches -

1. Download Vendor Source Code

$ mkdir workspace
$ cd workspace
$ svn export http://svn.automattic.com/wordpress/tags/2.3.1/
…


2. Importing Initial Vendor Drop

$ cd 2.3.1
$ svn import . http://svn.yourdomain.com/vendor/wordpress/current \
-m "importing initial WordPress vendor drop"
$ cd ../
$ rm -rf 2.3.1
…


3. Tagging Initial Vendor Drop

$ svn copy http://svn.yourdomain.com/vendor/wordpress/current \
http://svn.yourdomain.com/vendor/wordpress/2.3.1 \
-m "tagging WordPress 2.3.1"
…


4. Copying Vendor Drop into a New Branch

$ svn copy http://svn.yourdomain.com/vendor/wordpress/2.3.1 \
http://svn.yourdomain.com/branches/newproject \
-m "bringing WordPress 2.3.1 into the new branch"
…


5. Check Out and Add Customizations
We check out our project’s new branch – which now includes a copy of our first WP vendor drop – and we begin customizing or re-applying any changes to the code. Unless you’re starting from scratch, this probably just involves copying over any files and folders that were previously a part of your internal project code. Since we made sure to import the exact same version of WP that was used in our in-house development (this is not an upgrade) – there should be no conflicts and fewer surprises.

$ mkdir newproject
$ cd newproject
$ svn co http://svn.yourdomain.com/branches/newproject .
$ cp -a /path/to/your/oldproject/* .
…


6. Resolve conflicts and Commit Changes
Type svn status to see what files were modified and resolve any conflicts. Run svn add and svn delete commands where appropriate. Commit the changes and our modified version of WP is now completely integrated into our in-house project.

$ svn ci -m "commiting changes into the new branch"
$ cd ../
$ rm -rf newproject
…


That’s It! You’re Done.

At this point you might be thinking to yourself: “Well, that’s not exactly a time saver.. now is it?” And, you’d be right! But we won’t stop there! With WordPress integrated into our in-house versioning system – we can now use svn merge to quickly perform WP upgrades on our internal project code without risk of ever deleting or over-writing our own work.

And, best of all, every change made to your internal project code – including those made to WP core files – will now be documented and tracked from within your own local version control system.

[ Be sure to check back for the follow-up article entitled: "Using Subversion with WordPress - Part 2: Maintaining Vendor Branches and Upgrading WP Core Files" ]

From their site: “It has all the basic functionality of a mailing list manager, such as subscriber address management including automated bounce handling as well as message distribution and archiving. Its purpose is to efficiently send a message to a large number of recipients with minimal delay. It allows automated additions and subtractions from the subscriber database.”

i have seen it installed as the default built-in mailing list software for some shared hosting providers.
i needed a way to let visitors subscribe/unsubscribe to the ezmlm mailing list directly from a webpage.
but, when i searched the web for any existing WordPress plugins that could do this – i could not find any.
so, i thought there might be some wordpress users or admins that want to integrate ezmlm with their website using a standard web-based html signup form and some php magic.

description:
This plugin will allow visitors to subscribe and unsubscribe to your ezmlm mailing list – directly from your website – without having to manually send an email from their email client.

tested with WordPress 2.3.x
tested on Superb Hosting, and ezmlm mailing list software.

features:

1. basic error and spam checking built right into the plugin.
2. automatically prints out a “Thank You” or “Error” message on submit
3. you can use css to style the submit form to your heart’s content.
4. works even when your ezmlm is on a different server than you web server.
5. choose between using a standard text button or an image as your submit button.
6. choose between using the defulat privacy message, a custom message, or no message at all.

download:
ezmlm subscribe form v1.0

basic install:

1. download the plugin file, place it in the plugins directory, and active the plugin.
2. configure the plugin by going to Options > ezmlm signup form (see below for more details).
3. add the following code to your theme where you would like the ezmlm subscribe/unsubscribe form to appear.

< ?php if( function_exists('ezmlm_submit_form') ) { ezmlm_submit_form($display = true); } ?>

ezmlm options:
There are only 4 configuration options so far..

1. Set the Name of your mailing list (for example, you would enter: newsletter, if your mailing list was at: newsletter-subscribe@yourdomain.com)
2. Set the Domain of your mailing list (for example, you would enter: yourdomain.com, if your mailing list was at: newsletter-subscribe@yourdomain.com)
3. If you want to use an Image as the submit button: Enter the full URL to the image file (URL format: http://www.yourlocation.com/path/to/image.jpg – leave this blank and the form will use a standard text submit button)
4. If you want to set a custom privacy message: Enter it in the textarea provided (Or, type: DEFAULT and the default message will be displayed. Or, leave this area blank to have no privacy message displayed at all. Hint: you can use html in here too.)

screencap:

advanced usage:
- Template Tags –
To place ezmlm signup form on a specific page – like page 408 – add the following code to your page.php template file.
< ?php if(is_page(408)) {
if( function_exists('ezmlm_submit_form') ) { ezmlm_submit_form($display = true); }
} ?>

- Custom CSS -
You can style the signup form by adding the following IDs to your style.css file.
#ezmlmform (is the ID for the entire form)
#urlsubmit (is the ID for the image upload button)

/* example usage */
#ezmlmform { border:1px solid #000; padding:5px; }


credits:
Much of this code was borrowed from a forum thread called: ezmlm php subscribe/unsubscribe form
Documented here: http://forum.qmailrocks.org/showpost.php?p=16649&postcount=2.

This site was in maintenance mode for a good part of the evening due to an incompatibility with WP 2.3.1 and the previous theme used here on Techblog. I spent some time trying to work out the problems but the breakage was pretty severe so i figured it was time to either design something new from scratch, or just grab one of the many readily available WP themes and use that for a while. I decided to go for the latter choice.. i might still spend some time adding more customizations, but for now i needed something that worked well and looked clean.

Anyway, after trying out a bunch of themes from the WP Theme Viewer and playing around with the WP Theme Generator, i was able to narrow my choices down to about 5 themes and finally went with the blog.txt theme by Scott.

I’ve already made some SEO related modifications to the header.php template file. Also, i had to upgrade my tags structure – twice! Once from some really old wordpress tagging plugin that kept your tags in a key called: ttaglist, in the postmeta table. I had to use the UTW plugin to import these old tags. Then came the second upgrade. I used the new built-in tag import feature in WP 2.3.1 to convert my newly created UTW tags into the native WP tagging structure. Everything seemed to go smoothly, and i was able to get rid of all my old tagging plugins and install Simple Tags for advance tag management. I had to get rid of a few other really old plugins, but the site runs much faster now, and i’m sure it won’t take me too long to find a ton of new plugins to clutter up my site in no time!

So far, i have to say, i’m pretty happy with the upgrades. I haven’t tested everything too thoroughly yet, so more changes might still be on the horizon.. including another complete theme change. Just giving you all heads up!