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

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.

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.

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
[code lang="php"] $message['thumbnail_lightbox'] = T_('Thumbnail with LightBox link to Fullsized Image'); [/code]
[code lang="php"] $message['thumbnail_lightbox'] = T_('Thumbnail with ThickBox link to Fullsized Image'); [/code]

functions.js – modify javascript to do the actual inserting of code with Thickbox
[code lang="php"] htmlCode += ' Lightbox Options.
[code lang="php"] $img = str_replace('> [code lang="php"] $img = str_replace('/>