There are thousands of WordPress themes available for free and at low cost. That’s great! But how do you know if it’s going to help or hinder you in search engines? If you are shopping for a WordPress theme, chances are that you need to focus on your content, not on learning how to become a WordPress developer and WordPress SEO expert. These are all best practices for WordPress theme development too!

Before you begin looking at themes

It’s a good idea to sit down with paper and pencil and map out the content that you need to get onto your website. Draw boxes, make arrows, erase it and do it over until you’re clear on what you need from a theme and what your most important content is.

If you don’t do this beforehand, it’s likely that you’ll be drawn to something shiny that you then try to squeeze your content into … and that is the path to compromise. However, we’re just talking about the SEO-i-ness of themes here so I’ll leave the greater topic of how to prepare for choosing a theme for another time.

Here is a quick checklist to evaluate SEO friendliness of that theme you’ve just gotten attached to:

Page Load time:

Every WordPress theme should have a live demo available. You can run a website speed test at GTmetrix or WebPageTest or PingDom. These will tell you how well the theme is put together and make some suggestions for improvement.

Many of these metrics are dependent upon how you set up your website and your webhosting so do keep in mind that if the theme scores poorly, it doesn’t mean you shouldn’t use it, it just means you’ll need to do some extra work to improve it.

You may be interested in using a webhost that specializes in WordPress performance and security — if so check out WP Engine for WordPress hosting. They specialize in hosting fast and secure WordPress sites and that’s all they do.

Proper script loading, clean headers:

Commercial themes should enqueue scripts properly so they don’t conflict with other scripts. Most javascript should be loaded in the footer, not the header. Scripts should only be loaded on pages that they’re used on. These are all basic best practices in developing a website.

Content Structure:

The theme should accommodate the type of content you plan to publish. Content should be structured logically. Navigational menus should be marked up as nav items, lists should be list items, articles should have headers and paragraphs. Headers should be in order in the source code h1, h2, h3, h4 …
Test this by installing Web Developer Toolbar for Firefox — disable CSS and JavaScript so you can see the actual content structure.

Mobile Friendly:

The theme should look good and be usable on mobile devices. This data from Google Mobile shows that nearly 50% mobile site visitors call or visit a business after looking it up on their mobile device. That’s a lot of potential customers and a much higher conversion rate than even the best of websites have.

If you are a local business, you really can’t afford a website that isn’t both mobile friendly and optimized for local search. If you’re not yet convinced of the importance of mobile, here is a nice collection of 2012 mobile statistics

HTML 5/CSS 3/JQuery:

Any commercial theme you purchase should be marked up in HTML5. It’s a form of structured data and clearly demarcates what kind of content each section of the page is. CSS 3 can replace functionality that was previously delivered in JavaScript. WordPress includes JQuery out of the box so it’s also ideal if the theme uses JQuery rather than having to load up additional JavaScript libraries.

Structured Data:

Search engines are building their indices with sites that provide more descriptive structures around their data. Take a look at schema.org to get an idea of what I mean. Address, phone number, type of business, granular information about your business hours, products, and product options, contact information, authorship, and much more …. are all examples of types of content that search engines are trying to understand so they can present that information to searchers.

I highly recommend hiring someone to do this work as it can get a little involved. However, it’s nice for general types of content like contact information, address, and so forth to already be marked up in the theme.

Image optimization:

Over the past year, Google have updated image search algorithms quite a bit and I believe that image optimization is growing in importance to organic SEO. Out of the box, WordPress supports much of the image optimization that Google images is looking for: Each image in WordPress has it’s own “attachment” page which provides a canonical url for images. As well, you can create a template for image attachment pages to include metadata about images, short and long descriptions, titles, relations, meaningful filenames. If this isn’t supported by a theme, then you should really consider adding it.

Browser compatibility:

Make sure that the theme is compatible with your target browsers. Some users of the new WordPress default theme, TwentyTwelve, were perturbed when they noticed that TwentyTwelve doesn’t serve the desktop version of the website to IE 8 and older … instead it serves up the mobile layout to IE 8 and older.
Chances are that future WordPress themes will follow this lead. There’s nothing wrong with that, but if you want something else for older browsers, you need to know how much work you’ll put into updating the theme. If it’s already a child theme, you may have to decide between getting creative with a grandchild theme or forking the theme you’ve just purchased and losing out on letting someone else handle update maintenance.

Dependencies:

No theme should be dependent upon 3rd party plugins to function. Neither you, nor the theme developer has control over whether those plugins will continue to be maintained or developed.

Widget Ready Areas:

You will need to be able to include custom content in your sidebar or in widgetized content areas.

Social Media Integration:

It’s a nice idea for a theme to already support some kind of social media integration, but there are plenty of plugins for this too (check out rtsocial for nice lightweight social media integration).
I’ve noticed over the past couple of years that folks using themes with social media built into the theme find themselves limited when a new social media favorite comes along and it’s not easy to add it to the theme. It may be best to stick to plugins.

ok! well those are a few things to look at. If you really want to save time and money, you might want to work with a WordPress developer who can help you articulate your requirements for a theme and then help you review candidates. Consultants aren’t always custom code cowboys, sometimes they’re useful as advisers too.

originally posted at Evaluating a WordPress Theme: SEO Tips by chris
© SemioticPixels - (all rights reserved)

Redesigning and rebuilding a website is a lot like remodeling a house.  When you begin a remodel project, you don’t always know what challenges you’ll find until after you’ve ripped up the floors or torn down a wall.  If staying on time and on budget is important, then planning and communication are the most important elements of your web project management toolkit.

Here are a few areas that can hide surprises when launching a web development project and some suggestions to mitigate surprise.

The Antiquated Website:

Older websites may have a brittle architecture if they were not built to web standards (that’s why web standards were created).  Every time you touch one small thing something else breaks or looks wonky in unpredictable ways. “Spaghetti code” makes it difficult to make easy updates.

The website might be built on top of proprietary code that you can’t edit which means that over time you’ve probably cobbled together new functionality you’ve had to build and integrate into the interface. This becomes a maintenance headache.

Sometimes site owners want a design update but they think they can save money by not updating the code.  I’ve got news for you.  Modern websites look and feel good because the code looks and feels good. It often ends up being cheaper to build a new design in modern markup and code rather than trying to make old markup and code do modern presentation work.

If the web application is more than a couple of years old, hasn’t been updated and wasn’t built for ease-of-maintenance, it may be less labor intensive (i.e. less expensive) to plan for a rebuild.
If you’re uncertain of this, ask people bidding on your project to provide a comparative estimate for rebuild vs. refresh.

And last point to make about the case of an antiquated website is that to get an accurate estimate, you may need to give the potential consultant access so they can pull up some floor boards and evaluate effort.

Licensing:

License management and asset tracking software are common tools for IT managers, but for websites, unless they are very large, not so much. So outdated or overused licenses are often not discovered until a redesign project happens. You might want to audit the website for paid components for 3 reasons:

1. To include them in the budget
2. To ask project bidders to suggest lower cost or free open source alternatives
3. To renegotiate your licensing agreement if it’s up for renewal.

Other licensing areas that are often neglected:

Professional fonts: fonts need to be licensed properly so we can use them as web fonts.

Another often neglected licensing piece is worldwide usage rights to modify your website or application from your former developer. The SemioticPixels contract assigns rights to the client to keep everyone in the clear, but many web developers do not include this.  This is especially important if you’ve hired someone to build a custom application such as a mobile app.  Make sure your original contract does not contain language  requiring you to use your last developer to make changes.

Plugins and other web elements that you paid for when you initially built the website need to be maintained and updated.  If you’re updating your CMS, it’s pretty common that paid plugins also need to be updated and will have an associated upgrade fee.

Cracked Websites:

I actually see a lot of websites that nobody noticed were hacked.  While many website hacks are noticeable because suddenly you can’t log in and you’re receiving spam complaints from customers, the most successful hacks are more subtle and can go unnoticed for a long time if no one is paying attention.

If no one is monitoring your server usage, logs, or unauthorized file changes you may not know your website or server has been hacked until someone begins to dig into the code and discovers weird obfuscated code snippets embedded in random files. Or worse, weird code at the server root.

At this point, it’s nearly impossible to identify the source of the hack and the only real option is to change all passwords, reinstall the CMS from scratch, rebuild the server if it’s not on a shared host, and do our best to scrub the database.  And set up monitoring tools that will let us know if it’s hacked again.

Not all hacks come through your website. Over the past year, I’ve fixed a number of sites that were hacked repeatedly from a compromised web host. If you use a shared web host, it’s a good idea to set up google alerts or monitor discussion forums to learn of any issues as early as possible. They won’t send out a mass email declaring that they’ve been hacked unless there is loud enough public outcry and by then the damage is done.

A Project Plan:

A schedule of deliverables and the team or persons responsible can go a long way to helping the project along by clarifying roles and responsibilities.  Don’t forget to clarify user acceptance testing and at what point we call the project done. This should be part of your contract with your development team.

A Communication Plan for All team members:

You can save a lot of project management overhead by introducing everyone involved early in the project and establishing a communication plan.  This way, your design team, development team and system administrator can clarify details quickly.

When you’re ready to finalize the design, ask your developer to review it for completeness and to give ballpark cost estimates before signing off.  Often, your development team may offer feedback that will save your budget in production.

Also ask your development team to outline a server requirements document to ensure their solution is compatible with your hosting resources. Even if your development team will also be providing web host services, it’s still good to articulate hosting requirements so that you are clear on the ongoing budget impact.  In a best case scenario, your hosting requirements should be part of your scalability plan (see below).  In other words, you should have an idea of the traffic load limitations of your hosting at launch so you know at what point you’ll need to increase your hosting resources.

Scalability:

I believe that every website should have a scalability strategy no matter how small the site.  I believe this because I’ve spent days of my life without sleep, scaling small websites quickly for happy events such as being featured on Oprah, or a sudden “Slashdot effect”.

We all hope that our websites will become popular, but not having a plan in place for managing a sudden burst in traffic can be a real business opportunity miss.

Not only will a scalability plan give you peace of mind because you’ve already made the big decisions, but you’ll also have a ballpark budget to help you decide at what point to implement the scalability plan.

When you’re in the thick of it you don’t want to be distracted by trying to keep your website live. You need to focus on your business opportunity.

Budget and Price Negotiation:

There is this old sales mythology that whomever throws out a number first loses.  I disagree completely.  Negotiating price is not a game of winners and losers.

You have a budget and I have a time estimate.  You give me a budget and I’ll tell you what we can get done within your budget and how we might stage your project to meet your budget needs.

In a service industry such as web development, building long term relationships has greater value than competing for price and I’m going to work within your budget in order to build that relationship.  It really is that simple.

RFP Writing and Receiving Accurate Estimates:

It is in your best interest to receive accurate estimates, and it’s in your development team’s best interest to deliver accurate estimates.

Since responding to a Request For Proposal (RFP) is usually not billable time, many web developers and web development firms are somewhat judicious in which RFPs to invest their time.

If your RFP is well written, you are more likely to receive estimates from higher quality web developers who want to invest in the success of your project.

You should include the draft design comps with the RFP in order to receive a realistic and complete estimate. That way there are fewer, if any, surprises for you, and your developer will feel more confident in giving you a capped ceiling estimate if you ask for it. To avoid hidden costs, when you are evaluating estimates, look for transparency and true total cost estimates, not just the lowest price.

If the estimates you receive back are wildly different, you might want to revisit the details of your RFP or hire a consultant to help you write the website development RFP.   If your project is business critical, you might also consider using a consultant to assist in evaluating responses.

I hope that’s helpful. These are just some of my own experiences.  Please feel free to share yours!

originally posted at 8 Tips for Website Redesign on Time and on Budget by chris
© SemioticPixels - (all rights reserved)

I have tremendous respect for web designers – they are talented in ways that I will never be and most importantly, their designs are what makes my work look good.  We are such visual creatures that if the design isn’t beautiful, it’s hard for end clients to appreciate clever code.

The below is a checklist of information that makes it easier for the person developing a website to implement the designer’s vision.  When pieces are missing, it is essentially an incomplete design and that means that visual decisions are left up to the developer who may or may not get it right.   The ensuing rework can be demoralizing for everyone.

List of Hand-Off Documents

• A complete sitemap. It doesn’t have to be memorialized with boxes and arrows (although that’s nice) but we do need an outline of the site.
• Design document (see below)
• Itemization of fonts used including body font. Font sizes in px for each treatment.
• Color values used throughout the site (don’t forget color values for drop shadows and text shadows as well). While it’s true that we can get a close approximate from the design document, it won’t be exact
• Image aspect ratios. Does the aspect ratio change for smaller screens?
• PDF or jpg comps of every unique page in the sitemap. Here’s a short list of common pages:
  • home page
  • secondary pages
  • contact page
  • blog landing page
  • single blog post
  • search results page
  • 404 page
  • product category overview
  • individual product page
  • checkout funnel pages
  • landing pages

Acceptance Testing

• what browsers and operating systems must the website be tested on?
• what devices must the website be tested on?

Here are some questions that will likely need to be answered during development:

Design Check

• Check for background images that may overlap or have odd angles, especially images with multiple colors. Depending upon how they need to be positioned, images with multiple colors may not translate well as transparent images because they can only be matted with 1 color.
• The sitemap should be fully represented in the design document.
• Itemize: color values, fonts, font sizes, image ratios, grid details (does the design use a 12 or 16 or 24 column grid?).

PSD document:

The design document is the primary reference point for the developer. Even if the designer has done the production of images for the website, it’s likely that the developer will need the document at some point.  This is because the way images are chopped up for web production makes a lot of assumptions about how you think the site will be built.

• The document should be in well labeled layers, organized into folders by section of page/site. Anyone using the document should be able to turn pages and states on and off to get an idea of how the website is supposed to work.
• Images should not be rasterized with other layers. For example, an image that needs to be a background image in the site should be entirely in it’s own layer, not rasterized with a white background. This prevents us from producing it as a transparent gif/png if needed. It’s best if graphic images are imported from Illustrator into PhotoShop as smart objects so they retain their vector characteristics. If the execution plan includes using svg format images, we probably need the Illustrator document too.

Fonts & Typography

• We need to know exactly what fonts should be used in the design. Many responsive layouts are based upon a typograpic layout which means a font change is also a layout change.
• Ideally we’ll be using web fonts. If the fonts to be used are proprietary, the web font license should already be purchased and the files sent along with the handoff documents.
• If using proprietary fonts that must be produced as images for some reason, then those fonts should be converted to outlines in Illustrator and imported as smart objects into the PSD. This way they retain vector characteristics and the image will be higher quality in the case that the font is not available in developer’s font library. Alternatively, provide the font in hand off documents, but be aware that that may violate the font license agreement.
• For finer design control, itemize the fonts used on the website along with where they are used and recommended size. For example: what is the body font? what about headers? buttons? It’s fine to recommend a pixel size, we’ll calculate the em or rem from there.

State & Messaging

Most websites have some sort of state and messaging. Even the simplest website probably has a rollover state in the navigation or a series of error messages and success notification on a contact form. The Twitter Bootstrap framework has gained a lot of popularity because it styles common messages out of the box, which reduces the design load for small sites or web applications that need to be launched quickly. Personally, I’m all for it as it makes the web look better. However, if you’ve promised a custom design, then state and messaging should be representative your client’s branding, even if just branding colors.

• We need to be clear on what elements have state and how and when they change state. For example, in the comp, you can represent state for a navigation by grouping each state into a folder and naming it descriptively (primary nav, primary nav rollover, primary nav active, etc)
• In the case that javascript is turned off, how should these elements with state be displayed without javascript?
• How does the presentation of state change for different devices? For example, a mega-menu that looks great on a desktop will probably frustrate people on their mobile devices

Navigation

Most websites have multiple navigational menus: Primary navigation, utility navigation, sidebar/secondary navigation, footer navigation. We just need to know where all the menus are and how they’re supposed to behave.

• Comps should show all menus and their state
• how deep is the primary navigation (1 level, 2 levels, 3 levels?)
• If the website is to work on different devices, we need to see how the menu changes at different device breakpoints. Especially multi-level navigation

Layout

Nearly everyone I talk to about building a website wants it to look good on mobile devices as well as desktop. It’s much easier to build a responsive website when the design we’re given to implement has taken different devices into account. There is no magic wand to make a website look good on mobile devices, mobile layouts need to be designed as well.

• is the layout fixed or fluid? How does the layout change as the browser viewport is widened or narrowed?
• What devices does the website need to work on?
• what are the ballpark breakpoints in the design layout? (these may shift slightly in development but a ballpark is helpful). Have you considered tablets and mobile device screens in the layout?
• What grid are you designing to? (e.g. 12 columns, 16 columns, 24 columns?)

Images

Responsive images are still a hard problem that hasn’t been completely solved yet. For the moment, we have work-arounds such as making the image container responsive but the following information is helpful in maintaining image quality.

• what are the approximate image sizes for small, medium, large images?
• What is the aspect ratio of images?
• Does the aspect ratio of images change on smaller screen sizes?
• If the website needs to look good on high definition devices (Apple Retina is x2 and Android HD is x1.5) are the images large enough?

These are just the basics. The more complex the website, the more detail is needed from the designer to communicate that. Of course, in the best case scenario, the designer is available via chat during the build process so that questions and decisions can be addressed quickly.

originally posted at Seamless Web Design to Developer Checklist by chris
© SemioticPixels - (all rights reserved)

And now it’s fixed by the developer. 

A configuration vulnerability in W3 Total Cache plugin was disclosed on Dec 24.  W3TC is an awesome caching plugin for WordPress that is particularly great because it brings caching and minification functionality to WordPress installs that may not have a lot of server configuration access.  It does this by offering a disk cache mode for the case that your host does not have opcode (e.g. APC or XCache) or other caching mechanism (like Varnish) available.

If you are using W3TC on a shared web host, then you are very likely using it in disk cache mode.

Unfortunately, the database cache, which contains hashed passwords, is stored in the public web directory .  Not great.  It doesn’t matter if  you have directory listing turned on or not.  If you allow directory listing, it’s a lot easier to list out the dbcache, but as long as that information is available in a public web directory it is available and vulnerable.

The W3TC development team is already working on an update to address the issue.  Until they release an update however, it’s probably best to turn off database caching and flush the cache.

To do so

1. disable database caching in Performance -> General Settings by unticking the checkbox next to Enable.
   
2. at the top of the screen, click the button that says “empty all caches”
   
3. FTP to your website and check the directory in /siteRoot/wp-content/w3tc/dbcache/ and ensure that it’s empty.

That’s it for now!  Once the update is released you should be able to turn database caching back on.

Thanks for the heads up on the vulnerability go to the East Bay WordPress Meetup list.

originally posted at W3 Total Cache Bug by chris
© SemioticPixels - (all rights reserved)

While these WordPress SEO tips are applicable to any website, they are particularly easy to implement in the templating and theming structures available for WordPress SEO efforts as well as in web content management systems that follow a good MVC pattern such as Plone, Rails and Django.

I will be blogging on the Search Semaphore seo blog about semantic SEO and technical SEO in the upcoming year.  Here is an overview of google SEO changes in 2012 and some tips for 2013.

I am especially excited about the Knowledge Graph and structured data. Search engines such as Google are the organizational tools that make the web accessible to us, but the Knowledge Graph, brought to us via structured data at this time, is a grand effort at turning data into meaningful information.

This does add a bit of workload to theming websites, of course.  You’ll need to either familiarize with the structured data snippets on Schema.org to choose the structured data that’s applicable to your specific website or make sure that the person you hire to mark up your structured data understands your business.

Some of the snippets on schema.org are relatively generic (an address is an address, a phone number is a phone number) and in WordPress there is a plugin for those generic data types.  But they are so much more powerful when placed within the well thought-out context of your website’s topic/s and more useful when combined with an SEO strategy that addresses your website.

Anyway, here are some organic SEO tips for 2013.  Enjoy!

originally posted at SEO tips for 2013 by chris
© SemioticPixels - (all rights reserved)

I’ve been test driving WordPress 3.5 for about 2 months now. I don’t want to repeat all the same details that are already plastered across the web as well as on WordPress.org, so these are my thoughts in addition to that readily available information.

BackBone.js and Underscore.js integrated into Core

This is awesome! As Koop said at the SF Meetup a couple weeks ago, this brings WordPress closer to being a development platform that developers can build javascript applications on top of. Given enough traction, this is potentially a game-changer for WordPress as a lightweight CMS to WordPress as a javascript development platform. It will be really interesting to see what people build and I’m hoping to have time to build something interesting myself of course. I highly recommend watching Koop’s presentation

Lots of Plugins with Jquery 1.7 Dependencies are Broken

Slideshow, gallery and other jquery-dependent plugins are particularly clunky today because the WordPress 3.5 upgrade to JQuery 1.8.3 breaks most of them. I’m not sure why plugin authors have been so slow to upgrade their plugins but I do know that I have clients who have to wait to upgrade to 3.5 because their websites are dependent upon premium slideshow plugins that are broken in WordPress 3.5. The only gallery plugin I’ve found that claims 3.5 compatibility is MaxGalleria which I’ve never tried so can’t recommend. And NextGen Gallery appears to be working just fine. Probably because NextGen is more like a stand alone application than a plugin built on top of WordPress (it integrates but has fewer dependencies perhaps?)

And yes, while you could enqueue JQuery 1.7 on the frontend to make your plugins work, that doesn’t address those plugin dependencies on the admin side.  Many of them are broken on the admin side too.

ImageMagick is Cool

Another image-related cool thing is, if available, Imagemagick will be used to handle image resizing. ImageMagick is actually a collection of tools that can do a lot of things, excelling at compression and transformations: it strips out metadata embedded in images which makes the compression much better; resizes and compresses images at a compression % defined by you; transforms images e.g. create progressive jpgs, transform jpgs into WebP for browsers that know what that is, transform pngs into gifs for poor impoverished Internet Explorer.

I’m not really sure how WordPress is detecting Imagemagick and there isn’t any (quick) way to know whether it was used (add to do). The path to Imagick on Ubuntu is different than the path on say Red Hat or my Solaris-box-architected-by-crazy-FreeBSD-fans. And I know that at least when using NextGen Gallery, I have to manually input the ImageMagick path (/usr/bin/ or /usr/local/bin/ in case you’re looking for that). Being able to manually input the path and receive notice of whether imagemagick or GD is in use might be a good first addition to using ImageMagick in WordPress.

The new Gallery management is nice. I tend to forget about images on my own site, but my litmus test for most things is from a training perspective. I think that the new workflow will make more sense to new WordPress site owners. As with anything new, it will likely frustrate some old-timer WordPress users as well.  I’ll let you know how it goes when I do my first 3.5 training.

So, overall, I’m excited about all the new possibilities that WordPress 3.5 brings. However, I suspect that over the next couple weeks, the need for a good development->production process is going to be reinforced. Do NOT upgrade without testing first!

I do wish that perhaps WordPress had separated security patches from feature updates. It’s always a good idea to update as soon as possible for security, but a lot of people won’t be able to because of all the feature updates.

hm. Ok. Time to upgrade my own site now

originally posted at wordpress 3.5 released today by chris
© SemioticPixels - (all rights reserved)

Beta testing is fun and exciting, but there isn’t a push-button rollback path if you start to develop content in the beta version, then decide you have to rollback.

A couple weeks ago I had the bright idea that a photo-centric website launch coinciding with the planned WordPress 3.5 launch should launch on 3.5 …. so I built it out on the nightlies. It almost worked! But, with all the javascript changes, I decided it’s too risky to launch a new website on such a new release and I think it’ll be a while before the spectrum of plugins with javascript library dependencies (most of them) catch up to the javascript updates in 3.5.

While it’s true that you could always enqueue jquery 1.7 on the frontend, I’ve decided to wait for the 3.5 upgrade on this particular project.

I had 2500+ NextGen Gallery images so there are a couple of extra steps.

1. Keep the Beta Test site live and make it public (I had a couple failed tries before I remembered I needed to temporarily make both the Beta and stable sites public so they could know about each other). Use the WordPress export tool and download the content export
2. fresh install the stable version to a different path. Install plugins, configure permalinks to match the Beta version.
3. Install a default theme, I chose Twenty Twelve
4. import the content.xml file you downloaded from the Beta site. This will add in your menu items, pages and posts (you’ll probably need to reassign the navigation)
5. The import will likely fail on importing physical media especially from plugins like NextGen. Not a big deal at least for NextGen because NextGen stores Albums, Galleries, and Pictures info in its own database tables. Tar up the gallery folder and cp it to the new stable.domain.com/wp-content (or where ever it lived in the beta site). Do the same for any other media items that might have failed to copy over. If you’re using a plugin that squirrels information away in WordPress tables, you’ll have to look at the plugin code to see where to pull the data
6. in MySQL you’ll need to copy from the Beta database to the Stable database the wp_ngg_gallery, wp_ngg_album, wp_ngg_pictures tables.
7. proceed with building out the site on the stable version. Obviously if you developed a theme on the Beta version, some details in your theme may need to be rolled back as well.

hth!

originally posted at Roll Back from WordPress Beta Tester to Stable by chris
© SemioticPixels - (all rights reserved)

A year ago, I bought an Edimax USB wireless adaptor for my workhorse Ubuntu box. After spending a day sweating over my random collection of cheap old usb adapters and not getting any of them to work, I was pleasantly surprised when my Edimax arrived and proceeded to “just work” upon being plugged in.

A few days ago, I hosed my harddrive on that box (sigh) and had to reinstall the wireless adapter. It did not plug and play in the fresh install (obviously in my earlier attempts with the older USB adapters, I installed and blacklisted the right drivers for EdiMax to “just work”). In a quick search, I came across a few forums where my “plug n play” review was referenced on NewEgg so here’s a step by step (and NewEgg! No way for me to revise a review ?!?).

1. First, Ubuntu 12.04 includes the RT2800usb driver by default so you shouldn’t need to download it. However, if you do for some reason need to download it, EdiMax does not provide a Linux driver, but the EdiMax uses the Ralink RT2870 series USB chipset. You can download the Ralink driver which you’ll need to compile
2. Check that there are no collisions: sudo lsmod | grep rt If that outputs anything other than rt2800, you’ll need to blacklist the non-rt2800 driver to prevent a collision. sudo nano /etc/modprobe.d/blacklist.conf and add blacklist rt**** to the end of the file (where the **** represents the driver number)

I was able to connect to my network at this point, but then I tried to update to the non-free proprietary video drivers and that download seemed to freeze. So it might be advisable to reboot before updating the system.

A shoutout to the R statistics blog for reminding me about the need add conflicting drivers to modprobe blacklist.

originally posted at edimax wireless usb on Ubuntu 12 by chris
© SemioticPixels - (all rights reserved)

I’ve been beta testing WordPress 3.5 for a little while now and am building a photo-centric website that will launch after 3.5 is released. So, I’ve been paying particular attention to the media management in 3.5 as it’s been overhauled. I won’t claim to have nailed down the best way of doing things yet, but here are some things that I’m working toward right now.

WordPress media management now has a preference for using ImageMagick if it’s available on the server. If ImageMagick is not available, WordPress will fallback to GD library but it looks like it will only throw an error if neither library is available. So essentially if you want to use ImageMagick instead of GD for resizing images, you’ll need to install and test that it’s working serverside until someone decides to write an admin plugin that will tell WP admins that their server doesn’t have ImageMagick installed.

There is no WordPress UI (yet) for configuring the plethora of options available in ImageMagick, so by default WordPress is simply using it to resize images. This is still good because ImageMagick does a better job than GD of resizing images without losing quality and it will make it easier for plugin developers to extend.

At the time that I discovered WordPress 3.5 prefers IM, I was designing a commandline backend system to deal with images using both jpegtrans and imagemagick. I may still end up doing that since it might be faster to implement and then I’ll write a plugin for WP when I have more time. What I need the script to do is the following:

• resize images according to defined media breakpoints
• transform large jpegs into progressives and/or webP for Android/Chrome
• strip out unnecessary data
• compress! a lot!
• I want EXIF editing capability; namely I want to strip what’s unnecessary and add back copyright and geo location
• More bells and whistles, but those are the basics

Ideally, we can use the imagemagick library to construct well optimized images for mobile first and responsive designs while simplifying the workflow expected of the clients we’re building websites for. I’m not sure how mod_PageSpeed will interact with images already resized and compressed by ImageMagick. That will have to be a different topic and suite of tests.

I will write more in depth about 3.5 media management in other posts, but in the meantime, here are some resources:
http://core.trac.wordpress.org/ticket/6821 and also look at wp-includes/class-wp-image-editor-imagick.php and wp-includes/class-wp-image-editor.php

coming up …. I’m putting together a test page of images processed by a variety of tools (ImageMagick, jpegtrans, mod_PageSpeed) that I hope to get feedback on. Leave a comment if you think I should add a library to that list.

originally posted at WordPress 3.5 prefers imagemagick by chris
© SemioticPixels - (all rights reserved)

This is an update for Mac OS X 10.7 Lion of the mac path article I wrote for $PATH settings on Mac Snow Leopard

Managing Paths

Sidenote: /etc, /usr/, /tmp and more are actually symbolic links to /private/etc, /private/usr/, /private/tmp and so forth. In most cases this shouldn’t matter, when you navigate through a symbolic link, you’ll still end up in the real directory.  Where it does matter is if you want to back up your “dot files” … you’ll need to make sure your backup utility is set to follow symlinks.

The order of precedence for parsing paths in Lion is as follows:

1. /etc/paths
2. /etc/manpaths
3. /etc/paths.d/ filenames parsed alphabetically
4. /etc/manpaths.d/ filenames parsed alphabetically
5. ~/.bashrc
6. ~/.bash_profile
7. ~/.bash_login
8. ~/.profile

The Tao of Path Variables in Mac 10.7 Lion

1. /etc/profile is the default startup script for Bash, which is what I’m using. (If you’re using a different shell, then you may have a different startup script). /etc/profile calls /usr/libexec/path_helper
2. /etc/paths and /etc/manpaths contain the initial path environment variables. /etc/paths contains system-wide defaults:

   /usr/bin /bin /usr/sbin /sbin /usr/local/bin

   This is the file that you would edit if you need to parse /usr/local/bin before /usr/bin. (for example to make HomeBrew happy)

3. path_helper looks for files in the directories: /etc/paths.d and /etc/manpaths.d and appends the paths found there to /etc/paths and /etc/manpaths respectively.On my system, /etc/paths.d and /etc/manpaths.d contain a file named 50-X11 which simply contains the paths for X11.Each file in these directories can have multiple paths, one path per line. Load order is alphabetical by filename, then follows the path order in the file.
4. After /etc/profile has called path_helper, it then looks for ~/.bashrc
5. Bash next looks for ~/.bash_profile. This is the file where you’ll set file and directory colors and could also be where you place your Path environment variables.
6. Next, bash looks for ~/.bash_login. I don’t have this on my system so it’s ignored in my case
7. next, bash looks for ~/.profile

Another file that can contain path variables is /etc/launchd.conf (which may not exist by default). This sets environment variables, including paths, for GUI applications (as opposed to the above files which are read by Bash in your Terminal). I’m not building graphical applications so don’t have much to say about it.

Recap

So, what that all means is that instead of exporting PATH environment variables to a .profile or .bash_profile in a user account directory, you (or your application) can make PATHs global by adding text files to the /etc/paths.d and /etc/manpaths.d directories.

If you need to control the order of a path, then try this:
In /etc/profile, add a line PATH=”" before the call to path_helper like this:

PATH=”"

if [ -x /usr/libexec/path_helper ]; then PATH="" eval `/usr/libexec/path_helper -s` fi

References

man page for path_helper
making use of paths.d
mastering the path_helper

originally posted at Mac 10.7 $PATH settings and environment variables by chris
© SemioticPixels - (all rights reserved)