Skip to content

Reordering Style Sheets in WordPress

Dear Reader,

10/09/2019
Updated the code. The original code would not work properly if the array had any missing keys. (e.g. a style sheet was unenqueued). To fix this, I use array_values() to remove any gaps in the index before processing it.

The Lovely and Talented Kathy is responsible for how all our websites look here at EICC. If it looks good, she did it, if it doesn’t look good, I’ve obviously been mucking around in it and she will eventually fix it. Occasionally, she has need for my particular skills. Compared to her artistic pen strokes, my code in a sledge hammer, but when dealing with WordPress, sometimes a sledgehammer is what is needed.

With Stylesheets, order matters

I’ll never understand why theme and plugin authors don’t understand this one simple idea. User stylesheets should be loaded last. They should be able to override anything and everything because the end designer, not you the theme or plugin designer know what is best. Still there are some that simply insist that the the user’s stylesheet not be the last thing enqueued to load. I’ve grown tired of fixing this on each and ever site we have by digging into the functions.php of the last site we built to figure out how I did it. So I’m blogging my solution.

Hacking WP_Styles

What I found is that WordPress has a wonderful object called WP_Styles When theme and plugin authors enqueue styles, it adds them to this object. (For fun one day drop a print_r($wp_styles) into your functions.php. There is a LOT of stuff in there.)

One of the properties that I noticed when studying WP_Styles was the queue array. Looking at it, this was a list of the tag ids of the stylesheets to be queued. Examining the source of the page that was output, it was obvious that they were in the same order as the stylesheets were output. So I decided to test and see if the order of the array controlled the output order. Sure enough it did. So from now on, this little piece of code lives in the functions.php of every child theme she creates.

The Code

To use this, just identify the IDs of the style sheets you want to move, and add them to the $keys array.

1
2
<link rel='stylesheet' id='bootstrap-basic-style-css'  href='/style.css' type='text/css'/>
<link rel='stylesheet' id='it-exchange-child-theme-css-css'  href='/style.css' type='text/css' />

The stylesheets above are the two I have listed in the function below. Notice that each is appended with an additional -css. Make sure you do not put that in the code below.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
function cal_adjuststylesheets() {
  global $wp_styles;
 
  $keys=[
    'bootstrap-basic-style',
    'it-exchange-child-theme-css'
  ];
  $wp_styles->queue = array_values($wp_styles->queue);
 
  foreach($keys as $currentKey) {
    $keyToSplice = array_search($currentKey,$wp_styles->queue);
      if ($keyToSplice!==false && !is_null($keyToSplice)) {
        $elementToMove = array_splice($wp_styles->queue,$keyToSplice,1);
        $wp_styles->queue[] = $elementToMove[0];
      }
  }
}
 
add_action( 'wp_print_styles', 'cal_adjuststylesheets',99);

The last line calls this code just before the stylesheets are printed. Make sure you put that in there or WordPress will ignore it.  Order is important as the style sheets you specify will float to the bottom of the list but be in the order that you have specified.

 

WrapUp

Drop that little snippet in your functions.php and you never have to worry about your stylesheet being listed before the one you want to override.

Until next time,
I <3 |<
=C=

I was interviewed at WordCamp Nashville 2014

Dear Reader,

Most of the time when I am behind the microphone, I an the interviewer. It is my job to pronounce the guest’s name correctly, ask interesting questions, and try not to say “Ummm…”. (It’s harder than it sounds) Back in May though, I was the guest on a podcast produced by Clark Buckner of Technology Advice. It’s fun only having to worry about not saying “Ummm…” :)

Until next time,
I <3 |<
=C=

WordPress REJECTED MY PLUGIN!

The Rejection by Andreas WintererDear Reader,

One of the biggest complaints I hear about WordPress is that yes, you can choose from thousands of plugins, but many of them are crap. Because there was no barrier to entry, many of them were poorly coded and could even introduce security vulnerabilities to your site. I recently found out the hard way that WordPress is moving to change that. :)

First, they have been retiring old and unmaintained plugins for a while now. Thankfully, that includes all the plugins I wrote back in the 1.5-1.9 days. :) More importantly though, there is now a code review before accepting new plugins. This is a very good move on their part and I applaud them for this move.

There is a small problem though. They don’t seem to have published anything on what is acceptable/unacceptable in a plugin. In discussing my particular plugin with the reviewer, it seems the rules are kind of fuzzy as to what gets accepted or not, and they seem to be changing.

Overall, I think that a code review process is a very positive move for the WordPress ecosystem. It would be nice however, if the review team published the current rules. Even if those rules change, a current set of rules would help make sure that plugin developers don’t waste time and effort on plugins that won’t be accepted.

If these guidelines are already available, linking to them from “Writing a Plugin” would be apprecaited.

Well done, WordPress!

Until next time,
I <3 |< =C= p.s. I am working on updating my plugin to change the reported problem so that hopefully it will be accepted next time. (fingers crossed) :) Photo Credit: The Rejection by Andreas Winterer. Used under Creative Commons License.

Setting Up a (FREE) WordPress Development Site

Dear Reader,

The Problem

Most of you who read this blog are software developers. You know the importance of separate DTAP (Development, Testing, Acceptance, and Production) environments. However, not everyone understands this. I was recently at the WordPress Nashville meetup when someone mentioned having a development environment for their blog and you could here the crickets chirping. A lot of the attendees of that – and many other WordPress meetups – are not developers and may have never considered the need for a development area, after all, they don’t develop, right?

Everyone however, experiments. Whether it’s a new theme or a new plugin, you really, really need someplace to test things. one of the worst thing you can do is what I do with this blog, just install things and play with them in production. You need someplace where you can try out new plugins, new ideas, new themes. Not necessarily someplace where you post all your content, WordPress does a great job of allowing you to test things out content-wise before committing.

Development systems used to mean having your own server; as a matter of fact, I still do have one running here at the house. I do not recommend this though. It’s a gross waste of resources if you are just testing out a single blog, or even a few. You could also load WordPress on your laptop or desktop but I don’t recommend this either. To make it work though, you have to install and maintain a complete “web stack” (Apache, PHP, MySQL) This is just more software on your machine that has to be kept up to date.

There is a solution though, actually, I’ll present you with two. One for PHP developers who know what they are doing and want control, and one for regular bloggers who just want someplace to test plugins and themes before pushing them live. In both cases though, the services are free.

The Developer’s Solution

If you know what an ssh key is, and you understand source code control systems, then the solution you want is phpcloud.com. it’s a free service from Zend that is specifically designed for developers. phpcloud.com is a cloud-based development hosting. They host your project that you are working on, not the ones in production. You can’t use phpcloud.com for production systems. (and by can’t I don’t mean it’s against their ToS, I mean it won’t work. it’s not designed for that.)

Getting setup is easy.

  • Create an account. Find me on twitter if you need a beta invite and don’t know how to get one.
  • Create a Container.
  • Create an application inside that container. At this point, you have the option of selecting what kind of application, select WordPress.
  • Using git, clone the application to your local machine.
  • Code or experiment, commit, push, test, rinse repeat.

Again, this is a developer solution. I left out a lot of small details like setting up keys, etc. The docs tell you how to do that but if you aren’t familiar with the concepts, . You wouldn’t play with a jackhammer just because you thought ti was pretty, don’t play with tools like phpcloud.com unless you understand them.

Using phpcloud.com you can install themes, plugins, hack the core, (don’t you dare) or do just about anything else. To install plugins, you unpack them locally in the plugins directory, commit them to the repo and push. Then go into your test area and activate them. It’s not quite as simple as using the built-in installer but you know the saying “with great power…”.

Once you have tested a plugin, theme, widget or idea and know that it works properly, feel free to install in production knowing that you’ve done your due diligence.

I will mention one downside of phpcloud.com for WordPress developers. The automatic install and upgrade system will not work. You can try, you can fiddle with permissions all you want but at the end of the day, it’s just not going to work. Boaz and the team are aware of this shortcoming and it’s on their roadmap to fix.

The Blogger’s Solution

Ok, if you aren’t a developer, there’s still a way for you to get a free development area and it’s still important for you to test thing before you start mucking around with your production system. For you non-developers, use the free offering from my friends over at phpfog.com. Like phpcloud.com, there are limits to what you can do with the free offering but you should be able to get up and running with the free offering. The main limit you will hit is the 20MB space limit on your database. If you like phpfog.com, you may want to consider either setting up a pay account or moving all your hosting over to them. If you do the latter though, don’t just use your testing area as your new production area. If you do, you are really missing the point of this post.

  • Create an account at phpfog.com
  • Once in, select your “Shared Cloud”. (There is a button for it.)
  • Create an app in your shared cloud.
  • Select WordPress
  • Answer the questions.
    One of the questions is what domain name to use. If you are not familiar with DNS settings, use a phpfog.com subdomain. It’s easier that way. If you do understand DNS and know what you are doing, you can setup test.yourdomain.com or beta.yourdomain.com or something like that.
  • Be patient. No matter what it says, it can take up to five minutes for your app to be created.

Now you can begin installing plugins, themes, and widgets. If you are working with a developer, they can setup their ssh keys and get to the source code. Unlike phpcloud.com you can use WordPress’ automatic install and update tools to keep your test site up to date.

Wrap-Up

No matter which way you go – phpcloud.com, phpfog.com, or some other solution – every WordPress blogger needs to have a development area that is wholly separate from your production environment. This means don’t just install another instance of WordPress on your production server and call it test. It needs to be separate from your production server.

In this post we’ve discussed two solutions that you can use to get a test system up and running for free but there are other ways to accomplish this. The takeaway is not to use one of these services but to get a test system setup and use that for all your experimenting.

Until next time,
I <3 |<
=C=

Photo Credit: Huasonic
Released under a Creative Commons license.

Ecommerce in WordPress

Dear Reader,

The Problem

Regular readers know that back in November I put on a one day virtual conference titled Day Camp 4 Developers. Part of the deal was that all ticket holders got free copies of the recordings. It sounds like such a simple thing; just put them up for download, right? Not really. Let’s look at the actual requirements.

  1. Shopping cart to allow me to eventually sell the videos.
  2. A way to let my existing ticket holders “buy” them for free. (Coupon codes)
  3. A way to keep the real location of the files hidden so people don’t just go download them.

Those were the biggest items. Beyond that I was willing to either sacrifice or code it myself.

The Solution

I looked at a lot of shopping cart solutions ranging from the horrible to the expensive. I really wanted to go the open source route, not because I’m cheap or don’t believe in paying people for their work but I knew there would be needs I had that I would have to code myself. In that case, I wanted to be able to contribute back to the project. (Assuming they wanted the code, I wrote)

I ended up with eShop. It’s good, not great. It meets all 3 requirements, although I did have to help it along in a couple of places. I looked at the code, again, good, not great. It amazes me that after watching the PHP community scream “filter input, escape output!” so much that some developers still don’t. I had to add some filtering and a lot of escaping to get the results I wanted.

In the end though, it did the job. Like the other tools I used for DC4D, I could have written a more tailored solution myself, however, it would have take me a lot longer to get the job done and get the video’s up.

Side Note: I am so used to community projects being the norm that it surprises me when I find a project that is not community based. eShop is a single developer building a project. There is no repo for eShop and no way to submit patches other than just email them to the author. He has a forum for the project and it’s active enough to let me know people are using the product but there is no developer community working with him to mantain and enhance the project. It makes me sad. For those interested, no, he did not accept my patches but only because he didn’t want to take the project in that direction. I eventually forked it for my own use because I’ve modified it enough now that upgrading to future versions is a pain.

Conclusion

WordPress (“The word press” as one of the lovely and talented Kathy’s bosses used to call it) was never designed for ecommerce. Any solution is a bolt-on and feels like it. However, eShop is a good solution if your needs are modest.

Until next time,
I <3 |<
=C=