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.

(more…)

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.

(more…)

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

(more…)

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.

(more…)

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!

You can use this plugin to limit the visibility of your WordPress 2.3 site to only logged in users that have a specific (pre-defined) WP Capability. Any of the standard WP Capabilities can be used, like: read, edit_posts, publish_posts, edit_users, manage_options, etc. Custom capabilities can also be used.

Good for multi-blog setups with unified logins (single login with shared cookies) where you want some users to be able to access one site but not another unless they have certain permissions.

This plugin is based on Angsuman’s Authenticated WordPress Plugin. All I did was combine his redirect function with some of my own logic. Now you can have slightly finer grained control over who is allowed to acces your WP site.

Download:
You can get the Limit Visibility by Capability plugin (v1.0) here.

Install:
1. Place the file: limit_by_caps.php in your /wp-content/plugins/ directory.
2. Activate the plugin.
3. Navigate to the Options >> Limit Visibility subpage to enable your settings.

By default, after you activate this plugin it will:
1. Redirect all visitors who try to access your site (who are not logged in) to the Login page. (using Angsuman’s function)
2. Redirect all logged in users without the “manage_options” capability (everyone except the Admin) to http://wordpress.org

You can also Customize the Settings: (recommended)
1. Change the minimum Capability required to access the site to something lower. (eg: using publish_posts will typically allow all Authors, Editors, and Admins in - but not Contributors or Subscribers)
2. Change the external URL that logged in (but rejected) users get sent to into one of your choosing. (so if you are protecting a subdomain you might send these users to the top-level, “main” domain)

Here’s a screencap of the Options >> Limit Visibility subpage:

Additional Notes:
- Block posts, comments, searches, feeds
- Deny access to the entire back-end of WP (no dashboard, no write post, etc)
- No access to uploaded files (no images, no pdfs, requests for exact URLs still get blocked) still working on this..
- Works well with Options >> Privacy turned “On” (block search engines and spiders)
- Compatible with Postie plugin (post via email still works)

Well, i needed a choice/option that worked in a similar way but for Thickbox. Since both Lightbox and Thickbox are triggered by including special attributes on each anchor (a link) and pointing to a full-sized image - i figured it could not be that hard to find and edit the code that inserts the LightBox bit and swap it out for some Thickbox code.

LightBox format is: < a href="fullsized.jpg" rel="lightbox" >< img src="thumb.jpg" />< /a >
ThickBox format is: < a href="fullsized.jpg" class="thickbox" >< img src="thumb.jpg" />< /a >

All i ended up doing was adding the thickbox class=”thickbox” in addition to the lightbox rel=”lightbox”.

So the final result inserts the combined code into your WordPress posts:

< a href="fullsized.jpg" class="thickbox" rel="lightbox" >< img src="thumb.jpg" />< /a >

Now it works with either Lightbox or Thickbox scripts (i wouldn’t use both at the same time).
Note: you still need to provide the appropriate javascript (Thickbox or Lightbox) and link to it in your header file for this to work.

Tested with:
WordPress v2.3.1
Gallery2 v2.2.3 core 1.2.0.5
WPG2 v3.0.2

Anyway, here are the 3 WPG2 plugin files i edited to get this going:

wp-content/plugins/wpg2/g2image/g2image.php - [download the changed file here]
wp-content/plugins/wpg2/g2image/jscripts/functions.js - [download the changed file here]
wp-content/plugins/wpg2/wpg2embed.inc - [download the changed file here]

These are the exact edits i made (but watch out! because copy/pasting seems to change the single quote marks):

g2image.php - modify option to give choice (in dropdown menu of W2Image chooser) for specifically inserting Thickbox

functions.js - modify javascript to do the actual inserting of code with Thickbox

wpg2embed.inc - modify wpg2tag so option (in dropdown menu of W2Image chooser) will work with Thickbox [optional]
Note: for this to work you also need to have “Should WPG2 Tags have Lightbox Support?” set to “Yes” in your backend: WPG2 > Lightbox Options.

I know it was just released yesterday but for those of you who had already upgraded to WP2.3 within the last few weeks, you may have noticed the AWESOME NEW UPDATE NAG that appears in the back-end of your site !

WP2.3 now lets you know, automatically, as soon as there is a new version released. Then, a yellow nag message appears on every page in the back-end, saying: “A new version of WordPress is available! Please update now”. All very cool and useful, especially if you’ve gone and customized the Dashboard (with plugins or otherwise) so that you don’t see the headlines coming from WP.

My problem, as a site administrator, was that a yellow message also pops up for all my users. It says: “A new version of WordPress is available! Please notify the site administrator”. Now, some might not have a problem with this (and for most of my sites this won’t really be a problem) but for sites like indyish.com that have a lot of users, i personally wouldn’t want all of them notifying me of this. In fact, i probably don’t even want them seeing this notice at all.

So, all that to say.. i wrote a simple plugin that disables this notice for all - except - the site Administrator.

(more…)

here’s a great example (from their front page) of why i think that Scribd is such a great new web-based service (also one of the reasons i signed up):

i was able to resize the embed, favorite it, and as you can see it is downloadable in various formats like: adobe .pdf, word .doc, text file, and even streaming audio.

the whole experience was very intuitive, and since Scribd is extremely easy to use, i found myself compelled to read through the entire document (above) whereas under normal circumstances (ie: if it wasn’t already embedded in the page) i probably wouldn’t have. it sounds crazy, but a regular “download this pdf” link is usually one too many steps for me to take - and i would have just skipped over this “hidden” content, or downloaded it to my desktop and read it later (possibly never).

with Scribd, instead of asking myself: do i really want to download this? - i was already on the 4th page before i even thought of asking myself: do i really want to be reading this?

great app, a real keeper!

I’m not going to do a full blown review of their features since i feel their website does a pretty good job of that already.
Instead, i thought i’d make a list of features that i’d love to see added to Thinkature some time in the near future.

It’s be cool if:

• in “My Workspaces” i could provide short descriptions (instead of just titles) for each New Workspace i create
• in addition to having “My Workspaces” and “Recent Workspaces”, there was a “Archived Workspaces” (and let me archive ones i don’t use)
• in “My Account” there was a place where i could set my default landing page from “My Workspaces” to “Recent Workspaces” (it’s an extra click every time for me)
• in “My Account” there was a place where i could turn off those help/notification pop-ups (they slow down my machine and i know my way around by now)
• when inside a given workspace, i could click on the “Workspaces” icon (bottom-right corner) and get a link to “Recent Workspaces” (not just “Back to Homepage” and “Print this Workspace”)
• i could have users of a given workspace add objects to my shared workspace but not delete my objects (that might just be really wishful thinking, no pun intended)
• i could just export a given workspace as: jpg or png

I’ll try and keep this list up-to-date with any changes to Thinkature’s features (and maybe even add more items to this wish list the more i use their service). Also, if you’ve used this service and have any suggestions of your own, by all means add them to the comments section below.

In the meantime, for those of you who haven’t tried it out for yourselves, maybe you should. As long as nothing on this list seems like a show-stopper to you, why not give it a go? Personally, i’m going to keep using Thinkature to help organize and plan abstract ideas and other complex conceptualizations that usually start to make my brain hurt in that special way. For me, some things just won’t fit into a traditional spreadsheet. They never will, and so theres always going to be room for a web-based service like Thinkature.