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

Why?
Quickly turn an older machine into a modern Fedora Core 12 file server compatible with linux and windows clients. Less software installed means less setup, less maintenance, less updates, and less chance of human error somewhere along the way. The theory here is, the system starts out relatively secure and (if kept up-to-date) should remains so over time.

Side Note:
There are definitely many other ways to go about setting up a Samba server, much of which depends on your networking environment and overall requirements / constraints. This article is meant more as a guide – my notes which describe the method i happen to use – so that if i have to, i can do it all again.

Assumptions:
- Comfortable with install and use of Fedora Core Linux OS (command line)
- Basic understanding of networking concepts (setting up a static IP)
- Some experience with editing the smb.conf file

Features:
- No GUI / Desktop Environment
- Low RAM usage: boots up @ ~80MB with smbd and nmbd running
- SELinux and iptables firewall enabled / configured for use with Samba
- Samba Security level = User

System Resources:
CPU: AMD @ 700MHz
RAM: 192MB

Steps Involved:

1. Download and burn the Fedora-12-i386-DVD.iso file to dvd
2. Boot from the disc and go through install process (with less that 200MB RAM it defaults to text mode install – you can also force a text mode install at the boot: prompt by typing: linux text)
3. Once install is completed and system is rebooted, login as root
4. Check that networking is up
   - type:

   ifconfig

   (see if you have an IP address)
   - type:

   dhclient eth0

   (to use dhcp for now)

5. Bring the system up to date
   - type:

   yum check-update

   (to check for updates first)
   - type:

   yum update

   (say “yes” to install the updates)

- type:

yum list installed

(to see a list of all installed packages)

6. Check to see what package “groups” got installed by default
   - type:

   yum grouplist > grouplist.txt

   - type:

   cat grouplist.txt | more

7. Remove any unwanted package groups
   - type:

   yum groupremove "Mail Server"

8. Add the Samba package group
   - type:

   yum groupinstall "Windows File Server"

9. Configure Samba by editing /etc/samba/smb.conf
   - Note, for Vista support (in the Global section) add:

   client NTLMv2 auth = yes

   - Note, to hide unreadable files like /lost+found/ (in the Global section) add:

   hide unreadable = yes

   - type:

   testparm

   (confirm output has no errors in it)

10. Deal with SELinux security policies (see default smb.conf file for details)
    - type:

    setsebool -P samba_domain_controller on

    - type:

    setsebool -P samba_enable_home_dirs on

    - type:

    chcon -t samba_share_t /path-to-mounted-directories

    (remember to mount any/all directories first)
    - type:

    ls -ldZ /path-to-mounted-directories

    (to confirm it worked)
    - Note, for existing shares, to make sure this affects all files and folders recursively add:

    chcon -R -t samba_share_t /path-to-existing-mounted-directories

    - Note: to completely disable SELinux protection for smbd daemon (not recommended) type:

    setsebool -P smbd_disable_trans 1

    - Note: you can temporarily disable SELinux by putting it into permissive mode – type:

    getenforce

    to find out whether SELinux is in permissive [0], enforcing [1], or disabled [2] mode.
    - Note: to put SELinux into permissive mode (for testing purposes but not recommended) type:

    setenforce 0

11. Add samba users
    - type:

    useradd john

    - type:

    smbpasswd -a john

12. Configure the firewall to accept samba connections
    - type:

    system-config-firewall-tui

    (add an asterix next to the line: “Samba”)

13. Configure the network to use static IP/netmask/gateway/DNS info
    - type:

    system-config-network-tui

    - select: [Edit a Device Params] and remove the asterix from the line: “Use DHCP”. then, and add static info

14. Configure the network to use a static Hostname and DNS address (note: DNS settings may not be required)
    - type:

    system-config-network-tui

    - select: [Edit DNS configuration] then, and add static hostname and dns info

15. Get the network, smb, and nmb to start automatically next time you reboot
    - type:

    chkconfig --level 3 network on

    - type:

    chkconfig --level 3 smb on

    - type:

    chkconfig --level 3 nmb on

    - type:

    chkconfig --list network

    (or smb, or nmb to confirm it worked. you can also leave out the servicename to see a list of all services)

Reboot.
Use another computer to check that everything went well.

Optionally:
1. Install NTFS support.
- type:

yum install ntfs-3g

2. Once it’s done downloading/installing, figure out which device it is (for me it was /dev/sde1) and mount it.
- type:

mount -t ntfs /dev/[your-usb-device] /media/

3. Deal with selinux and ntfs support
- type:

setsebool -P samba_share_fusefs 1

Anyway, here are all the new webapps and firefox extensions i picked up (and “stuck” with me) over the course of the year:

Web-based Tools:

• Twitter – Just started using it (less than 3 months ago), but obviously it’s a keeper.
• Brizzly – Best web-based Twitter app i could find.
• ReadItLater – One click bookmarks, online sync between browsers, delicious integration.
• Su.pr – URL shortener of choice with Twitter and StumbleUpon intergration
• Feedly – Next generation feed reader with Google Reader and Twitter inegration
• Shareaholic – Social networking tool that integrates with tons of popular services including Su.pr, Del.icio.us, and Twitter.

Here’s some stuff i’ve been using for a while now and will continue to use – although technically all of these were restored from my older backup and i won’t be linking to or describing each of them at this time.

Web Apps:

• Del.icio.us – Still my online bookmarking tool of choice.
• Google Products – Gmail / Docs / Reader (and more but i don’t feel like going into detail here).

FireFox Extensions:

• All-in-One Sidebar
• Download Sort
• Download Statusbar
• Firebug
• Link Evaluator
• Live HTTP Headers
• BookmarkDD
• SEO for Firefox
• Tab Kit
• text/plain
• Web Developer Toolbar
• YSlow

Also, I was impressed by the decreasing number of desktop softwares i needed to reinstall.

Desktop Apps:

• VMware player (win/linux)
• Firefox (win)
• 7zip (win)
• unrar (linux)
• Inkscape (linux)
• gftp (linux)

That’s all i could think of at the moment. If i missed any important ones, i’ll probably just add them to the list. I’m sure there are many other great web-based tools out there. These are just the few i’ve been using. I wonder what new and cool webapps will be added to my arsenal in the coming year? In the meantime, feel free to use the comments below to let me know if you’re using a great webapp not mentioned here.

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 ;)

Have you ever tried increasing the size of a vmdk file / virtual hard disk ?
It’s not that easy.. and it’s kind of confusing.

So, once i finally figured out how to do it, i thought it would be useful to write it down so that i wouldn’t forget next time this happened. Here goes..

In my example i have:
- a Windows Vista host OS running a Fedora Core guest OS
- an 8GB vmdk file (formatted as Linux LVM – fedora fs) on the guest OS which i have backed up before attempting anything here !!!

I want to:
- increase the 8GB vmdk file to 16GB
- not lose any data saved on the vmdk file
- not move any data off/on the vmdk file

Follow these Steps:

1. Download and Install: VMware Workstation for Windows (trial)
2. Note the location of the VMware Workstation folder (after install) – in my case it’s “C:\Program Files\VMware\VMware Workstation”
3. Open a Windows Command Prompt and navigate to the folder where your vmdk file resides and execute the following command:
   "C:\Program Files\VMware\VMware Workstation\vmware-vdiskmanager.exe" -x 16GB "Name of Your Virtual Disk File.vmdk"
   Ok, now you just made the disk twice as big but you can’t use the space yet because it’s inactive, unpartitioned, unformatted, and still utterly useless to us. (but not for long)
4. Next, boot up the guest OS and log in as root. Verify that there is in fact a large amount of unallocated space/sectors by typing the command: fdisk -l
5. Then we’ll partition and format the new portion of the disk. First select the disk: fdisk /dev/sda
6. Type “n” at the fdisk menu to create a new partition
7. Type “p” for primary partition, and then select the appropriate partition number, as well as first and last cylinders to set how large to make the new partition (defaults – ie: use all the free space – worked well for me here)
8. Type “t” to change the partition’s system id, then type “8e” to switch it to Linux LVM
9. Type “w” to write the table to disk and exit fdisk. You might get a warning about needing to reboot for changes to take effect – either way, reboot your guest OS just to be safe.
10. Once rebooted, log in as root again and verify the new partition exists. Type “fdisk -l” to see a list of partitions. In my case, the new partition is: /dev/sda3
11. Now comes the confusing part. We’re going to merge the new partition into the current Volume Group (which is just what fedora calls it’s own virtual disks that are made up of a bunch of virtual LVM partitions). So, first, to “create” the necessary “physical volume” from our newly created disk partition (/dev/sda3) first type: pvcreate /dev/sda3
12. You need to find out the name of the Volume Group before you can extend it to include the newly created physical volume. Type: vgdisplay and look for the first line, “VG Name” – in this case it was VolGroup00 [thanks agm]
13. Next, you need to extend the Volume Group to include the newly created physical volume. Type: vgextend VolGroup00 /dev/sda3
14. Then, type: pvscan You should see the new partition (/1dev/sda3) in the list of partitions and the total should read approximately 16GB (the amount we set earlier). In my example, it said 15.75GB
15. Now type: lvextend -L+8GB /dev/VolGroup00/LogVol00 to increase / extend the Logical Volume by 8GB (to a total of 16GB).
16. Finally, to resize the filing system type: resize2fs /dev/VolGroup00/LogVol00

Now your fedora guest OS should have twice the amount of space and your VM should be running smoothly.
Repeat this process if / when the vmdk file gets filled up again and runs out of space ;)

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.

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" ]