I decided to make a plugin and it did the trick. I’ve consequently shared it on wordpress.org in the hopes that it helps someone out. This simply creates a list for each WP User role (custom roles included) and keeps the list synced when moving old and new users in and out of these roles.

The post Role Based Lists for MailPoet Plugin appeared first on Marcus etc..

These plugins are Disable User Gravatar, Localhost Notify, Cursor Trail

They all needed surprisingly little to get back up and working again. Disable User Gravatar and Cursor Trail actually worked out the box but spat out a few PHP errors.

In all cases some reorganization of code, updating it to use some ‘best’ practices will have improved functionality and performance. Mostly, they got a clean up, and maintaining them should certainly be a lot less (if any) time-consuming.

The post Weekend Plugin Resurrection appeared first on Marcus etc..

This was my first ever plugin to be submitted to the WordPress repository over 7 years ago! Back in the day, there weren’t any (or none I found) plugins that would allow you to add meta tags to your site. This was somewhat a pain for me whenever I needed to add google or yahoo verification meta tags to connect to their webmaster tools. Sure, you can edit the theme header, but that presented problems when updating the theme and was also just less convenient overall.

Over the years, other plugins came out that served my purposes, and in other cases I just verified my sites over DNS. As other plugins took up more of my time, this one fell by the wayside, and it has been four years since my last update!

However, I still get people asking me every so often whether I can update it. There’s also a surprisingly large number of active installs, so I felt it only fitting for my first ever (publicly released) WordPress plugin to get a spruce up. Moreover, it’s a refreshing change of pace to work on a plugin that is less complex than some of my popular ones.

The main aim of this first rewrite was to:

• Get it up to latest coding standards of WordPress, which includes security best practices and getting rid of outdated PHP methods causing warnings.
• Keep it lightweight
• Improve the UI for creating meta tags, which restricted the creation of tags with only the name property.
• Allow for limiting these tags to show on certain page types (CPTs, Taxonomies for now) along with the option to show on all pages or just the home page as before.
• Allow for adding specific meta tags to Custom Post Types

Additionally, I’ve integrated the Freemius Insights service to make use of their feedback data collection features and allow the users to optionally share some usage stats, which will hopefully make our plugin better.

I’m curious to see how useful people find the plugin, and certainly intend on at very least maintaining these features, ensuring they work with newer updates.

Other possible plans/ideas for this plugin are:

• Allow Taxonomy-specific meta tags.
• Add placeholders for global meta tags, allowing insertion of dynamic data
• Making it easier to set up Open Graph and Twitter meta data.
• Multi-lingual support
• Make it extendable through hooks/filters to allow other devs to add their own.

There’s already plenty to go on for now, but I’m open to ideas and may well tackle other features if they’re in demand. Feel free to let me know!

The post Meta Tag Manager 2.0 appeared first on Marcus etc..

Over the past few years due to work, time constraints, life and other priorities, this blog along with various WordPress plugins I had written in the past have been neglected. My last post was in 2012…. yikes! Yet funnily enough, I still refer people to that post as recently as this year, so the thought that I could be writing something that’s useful to someone is certainly an inspiration to get this going again.

I also have plugins that haven’t been updated in many years, and still seem to have a following. Therefore, I’m committing to reviving some of these plugins and showing this blog some love.

First step, this site has had a much needed refresh, and I hope on improving my post frequency. In the spirit of not over-promising, we’ll keep it at that 🙂

More importantly (to me at least), I’d like to see some of my plugins that fell by the wayside get updated and keep provide value again. Every so often someone tells me they’re using one of these older plugins because it solved a problem for them, and it always warms my heart to hear that, along with a surprise that they still work! Also, most of these plugins are minute in comparison to my more popular ones, and are a refreshing change of pace.

With the intent of hitting the ground running, I’ve done a full rewrite of my first ever plugin, Meta Tag Manager, which I originally wrote sometime in 2008 and committed to the repo in early 2009. That was fun and has given me food for thought on what features I could add to it. I’m just polishing that off for release and looking forward to the feedback!

I’ll then be contemplating which plugin to revive next, but meantime I’m open to suggestions!

The post A Year of Revival appeared first on Marcus etc..

For plugin developers like myself, it’s a pain in the @!+ as I’m now seeing users run into this problem on a daily basis for a few weeks now, and it has become obvious that the problem in every case is the forced loading of jQuery library files from CDNs, particularly Google.

The aim of loading jQuery libraries from external sources is to speed up page loading time, so no wonder why theme makers jump at this quick speed upgrade.

However, whilst there’s nothing wrong with doing this theoretically, they way they’re going about it couldn’t be more wrong! The various misleading posts circulating the web are most likely the cause of such a widespread problem, and now we’re starting to see the consequences as time passes.

Why is this wrong?

As I mentioned above, there’s nothing wrong with loading files from a CDN, however, there’s two major things themes do wrong:

The first major issue is that I have yet to see a theme that does this load the latest jQuery version used by WordPress! This presents a load of problems because other plugins that rely on the jQuery library are forced to use outdated libraries which may conflict with some of the code written with later library versions in mind.

The second major mistake is that they’re taking it upon themselves to do this in the first place. My opinion is that themes have no place in messing with the jQuery libraries and WordPress dependencies. Themes should must take into account that plugins will be installed, and these plugins should have access to the standard libraries provided by WordPress.

How can I check if I have this problem?

The major browsers these days all have their own code viewers which makes it easy to check which scripts are loaded. The screenshots below show how this is done in Google Chrome, which is also similar to doing this with FireFox and the Firebug extension.

To bring up the developer window, right click anywhere on the webpage and the click on ‘Inspect Element’. You’ll see a window appear similar to the one below, click the Sources (in FireBug it’s Scripts) tab, and look at your scripts there:

As you can see, the location of the jquery.js file is on the Google server, and clicking on that file shows you the contents which includes the version number (it’s also usually in the URL). In this case, the theme is loading jQuery 1.4.4.

Where does my theme do this, and how do I fix it?

This is the most common question I get these days, which is what inspired this post. Thankfully, the approaches taken by most theme are the same, or similar therefore easy to identify. Unfortunately, not all will be so lucky.

In either case, when trying to find the location of where this is done, you’ll need to use search functions in your text editors.

Typical – functions.php

This is the usual situation.

wp_deregister_script('jquery');
wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js', false, '1.4.4');
wp_enqueue_script('jquery');

The solution is easy though, just delete it! WordPress will then start loading its own copy of the jQuery library.

Worse – header.php

Less often, but astoundingly too often, some themes go ahead and hard-code the jQuery file with pure html similar to:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js" />

This is worse because it goes against the whole dependency system WordPress uses to load the right scripts during the wp_head() function executed usually within the header.php file.

The fix involves one to three steps (depending on how many mistakes your theme maker made):

Step 1 – Remove the line above.

Step 2 (if step 1 fails) – Your theme may be doing something even naughtier which is failing to include the wp_head() PHP function in your document head, meaning plugins like Events Manager can’t include its own javascript files. Try replacing the line you just deleted with this:

<?php wp_head(); ?>

Step 3 (if Step 2 fails) – If you had to add wp_head(), chances are you’ll need to add wp_footer() too, which is done within your footer.php file above the body closing HTML tag.

The upside once you fix this is that your theme will now work with more plugins. However, if you had to do step 2 or 3, you may want to reconsider where you get your themes from (if you made it yourself, lesson learnt i hope!).

Worst of all – unknown

Your theme maker decided to get uber fancy and demonstrate their skills by making this modification somewhere in the myriad of custom included files. Your best bet is to use a search tool and look at all your theme files for words like jquery or google.com. Chances are if the mod isn’t done in your header.php file, they used the method for the function.php file.

If your theme has found another ingenious way of doing this… I’d say your theme is too smart to be used on WordPress, save yourself the headache and move on.

The ‘Right Way’ to host external libraries

Whilst there’s more ways than one to do this, the two most sensible ways to do this are:

• Use a plugin that does this for you, such as Use Google Libraries and makes sure the right jQuery version is loaded according to your WP version.
• Host all your javascript, css, image and other files on a CDN such as Amazon S3 or CloudFront. It’s cheap and effective. Caching plugins such as Super Cache or W3 Total Cache make this very easy to set up and are well documented.

Between the two, if you can make use of minify functions (W3TC has this function) to merge all js files into one cached file, then the best choice is the second one if your end goal is increasing your page speeds and/or reducing your server load. However, if you’re on a budget, or you’re having issues minifying your scripts with caching plugins then Use Google Libraries will still help a lot and is highly recommended.

As you can see, these have nothing to do with your theme, as it should be!

The post jQuery CDNs and WordPress theme conflicts appeared first on Marcus etc..

It has gotten to the point that it made sense to split my posts from any company blogs and move it over to a personal space. I hope to find the time to write more, particularly tidbits, tips and tricks on my day to day work with web technologies, along with the possibility of a rant or two about something or other.

So… I’m almost starting from scratch. All my posts on netweblogic.com have been moved over. I may have lost some comments in the process (which is why you shouldn’t go with plugins like Disqus), but if more content is produced as a result this move, then it will be worth it.

Under the Hood

I’m a fan of simplicity, as well as not re-inventing the wheel (especially when you can improve it!), so I’ve gone with the lovely Elegant Themes Modest theme with some minimal CSS changes, which does what it says in the box, and will allow more focus to be placed on the content. I may even take it a step further and simplify it even more by removing unnecessary scripts, fonts, etc.

Welcome to my new online home. Don’t expect regular posts anytime soon, but hey, that’s the goal and this is the first step 😉

The post My new home….. appeared first on Marcus etc..

Fortunately, wordpress makes this sort of customization easy with its amazing API. These four lines of code are all that’s needed:

function my_wp_admin_ban(){
	if( !current_user_can('activate_plugins') ){
		wp_redirect( get_bloginfo('wpurl') );
		exit;
	}
}
add_action('admin_init','my_wp_admin_ban');

You can get this working in two ways:

1. Copy the contents above into a file named wp-admin-ban.php (put them between ) and move it to wp-contents/mu-plugins folder. If the mu-plugins folder doesn’t exist, create it. This will be available across any theme on your site.
2. Copy the code to your theme’s functions.php file, which restricts functionality to that theme.

If you can think of a good membership plugin on the wordpress repo that does the trick, feel free to drop me a line!

On that note, here’s two plugins you might find useful:

• My own ajax login plugin so users can log in and register with smooth ajax effects from the front of your site!
• Membership Plugin If you’re looking for a good premium membership plugin with great support (personally recommended, tried a few others before it). They also have a lite free version for you to try out.

The post Redirect users from WordPress admin pages appeared first on Marcus etc..

This was inspired by David Walsh’s MooTools implementation. Check out his demo to see functionality, it’s the same thing except you can control the fade speed and cursor image, as long with start/end dates for special occasions.

Activate it for Valentines Day for a special surprise, if that’s today you’ll know what I mean 🙂

Download it here!

Installation

Download the zip file, and either:

• Unzip and upload the cursor-trail folder to your plugins directory, then activate in your plugins page.
• Upload via the add new plugin feature in your admin area.

The post New Plugin – Cursor Trail appeared first on Marcus etc..

I came across a problem like this where a custom theme I made needed to accommodate the multilingual capabilities of qTranslate for some small snippets of text here and there which could be added in the theme options page (e.g. address, slogans etc.). The amount of work that would be required to make a multilingual options page was not justifiable for the project. So…. I came up with a pretty simple solution which I’m sure others can easily use in their plugins and themes:

Basically, if used, you can pass along text wrapped in curly bracket tags, much like html except the tags use curly brackets and the tag names are the language code(e.g. en_US, de_DE, fr_FR). The result is that you could add this to a text box:

{en_US}english text{/en_US}{fr_FR}french text{/fr_FR}

With the above string the function will choose the correct language based on the current wordpress locale, and if that doesn’t exist, revert to the first language in the string. This is also compatible with non-translated strings. Whilst not ideal for a whole post, this would definitely come in handy for smaller snippets of text, such as widget titles, theme texts, etc. where fully fledged translation functionality is not needed.

Without further ado, here is the function:

/**
 * Separates a string by {lang_code}{/lang_code} 
 * style wrappers and returns the desired locale. If the locale 
 * parameter is empty, function will use default locale (e.g. en_US).
 * If no local is matched, the first language is used. If no brackets 
 * are enclosed, the $string param is returned as is.
 * @param $string
 * @param $locale
 * @return string
 */
function ml_string($string, $locale = ''){
	$locale = ($locale == '') ? get_locale():$locale;
	//Do a regex and extract all text within braces
	$matches = array();
	preg_match_all('/{([a-zA-Z_]{5})}([^{]+){/[a-zA-Z_]{5}}/', $string, $matches);
	if( count($matches[0]) > 0 ){
		//Check if the language we want exists, if not we take the first language there
		foreach($matches[1] as $key => $lang){
			if ($lang == $locale) {
				return $matches[2][$key];
			}
		}
		return $matches[2][0];
	}
	return $string;
}

The post Single string with multiple translations appeared first on Marcus etc..

If you’d like to add or remove a specific filetype that can be uploaded to wordpress via the media library, you can insert this PHP code in your theme functions.php file:

function my_myme_types($mime_types){
	//Adjust the $mime_types, which is an associative array where the key is extension and value is mime type.
	return $mime_types;
}
add_filter('upload_mimes', 'my_myme_types', 1, 1);

Here is an example of what you can do to add and remove a new filetype (in this example, I’m adding an extension that already exists, but the concept is the same):

function my_myme_types($mime_types){
	$mime_types['avi'] = 'video/avi'; //Adding avi extension
	unset($mime_types['pdf']); //Removing the pdf extension
	return $mime_types;
}
add_filter('upload_mimes', 'my_myme_types', 1, 1);

You can also reset the allowed filetypes by creating a new array within the function and returning these values:

function my_myme_types($mime_types){
	//Creating a new array will reset the allowed filetypes
	$mime_types = array(
		'jpg|jpeg|jpe' => 'image/jpeg',
		'gif' => 'image/gif',
		'png' => 'image/png',
		'bmp' => 'image/bmp',
		'tif|tiff' => 'image/tiff'
	);
	return $mime_types;
}
add_filter('upload_mimes', 'my_myme_types', 1, 1);

If you’d like to see what filetypes are currently supported by wordpress, check out the function get_allowed_mime_types located in the wp-includes/functions.php file.

The post Adding & Removing Allowed FileTypes To WordPress Media Library appeared first on Marcus etc..