Stylesheet files can get ridiculously long. The Twenty Eleven theme has over 2500 lines of css (unminified). That can be a pain if you’re trying to make significant adjustments to a theme. Quite a few theme frameworks take a more modular approach to css and separate their CSS into different files. That is a big improvement, but it does come at a cost. The more files you import, the more requests you’re making to the server. Secondly, persons who have to work with the CSS now need to figure out what files contain what style specifications. Thirdly, the built-in editor in the administration screen is not that user-friendly when you have to hunt down specific files instead of editing the basic style.css file.
I use the LESS language these days which makes CSS management heaps easier. You can have multiple less files and you can generate a single css file from those files. The question now becomes: what’s a good way to organize the less files?
There are quite a few different ways to organize your CSS logically and the problem here is that you can easily run into overlap situations. Do you put your CSS targeted for small screens in a separate file, or do put them in the file that targets those specific elements? If we have a file dedicated to structure as well as for different content elements, from widgets, to post-formats, how do we make the separations? If you have CSS for your images, do you include them with the file that handles galleries, or do you put them in the file that addresses media elements. These are just a few examples.
So far, I haven’t come up with a system that has perfect clarity. I don’t think it’s possible. The conclusion I’ve come to is that you have to do what’s most in alignment with your workflow. If you have to figure out what file to make an adjustment, there should be no more than 2 obvious candidates to choose from, and they should be obvious. If I want to make an alignment adjustment to a widget area for tablet screens, I don’t want to have to check a widgets file, a structure file, an alignments file and a responsive file.
I’ve been taking advantage of the LESSphp library to get around some of these file organization dilemmas. You can drop in your media queries like you would do a mixin. That way you can keep all the CSS relating to a group of elements organized in one logical area. There is one downside at the moment: the output isn’t perfect yet since it can cause your CSS to contain a lot of redundant data (similar media query statements aren’t grouped automatically into a single media query). I’m working on a css post-processor (the Flawless Styles Compiler plugin) to fix this and make the output cleaner and lighter in general.
Here’s my current file organization setup for those that are interested:
- variables.less
- mixins.less
- reset.less
- structure.less
- typography.less
- general.less
- navigation.less
- header-area.less
- footer-area.less
- page-templates.less
- post-formats.less
- media-elements.less (images, video, audio etc)
- form-elements.less (input elements, search box, contact forms etc)
- ui-elements.less (button’s etc)
- sliders.less
- gallery.less
- comments.less
- states.less
- print.less
- widgets.less
- misc.less
Potential tweaks to this organization? I’m thinking further separation of individual page templates and post formats. Post types can fall into either page template or post format category but it might make sense to have a dedicated file for post types as well.
LESS and convenient file organization make things a lot easier. But I want managing a site’s design to be even easier and this is why I’m building a plugin called ‘Flawless Styles Compiler’ which will take CSS development for WordPress to a whole new level.
A very common requirement for membership sites is the ability to send a user that is logging in to a specific home page. With S2Member there are a couple of ways to accomplish this. I came across some solutions involving javascript, which I think is a bad idea for a number of reasons. I’ll share one method here that is relies on some server side magic instead. To implement this you’ll need to write a little bit of code and insert it in your plugin file, your theme’s functions.php or your s2hacks.php file.
The first clue to redirecting users after logging is the UI S2Member provides under ‘General Options’. There is a section called ‘Login Welcome Page’, which is what we’re after. Here S2Member gives you the option to select an existing page from a dropdown. We don’t want that option because it will be the generic welcome page for all user levels/roles. To send users to different pages based on their membership level, we can make use of the field below the drop down.
It’s basically a text field that let’s you specify a url. The cool thing is that we can utilize dynamic variables in the url with replacement codes. The solution I’m using here involves using the %%current_user_role%% replacement code as a GET parameter in the url. What you get is a url that looks like
http://yourfabulousmembershipsite.com/?custom_welcome_page=%%current_user_role%%
The words custom_welcome_page can be replaced with a wording of your choosing (make it unique though) and the %%current_user_role%% will be dynamically replaced with the membership level of the user that is signing in.
For the next step, we are going to write the code that tells WordPress to interpret those parameters.
[php]function your_member_site_vars( $vars ){
$vars[] = “custom_welcome_page”; return $vars; }
add_filter( ‘query_vars’, ‘your_member_site_vars’ );[/php]
And now WordPress will interpret the parameter we’re using, we have to tell what to do when it is used next.
function my_login_redirect() { if ( get_query_var( ‘custom_welcome_page’ ) ) { $role = get_query_var( ‘custom_welcome_page’ ); // double check if user has that role if( current_user_can( $role ) ){ wp_redirect( my_member_welcome_pages( $role ) ); exit; } }
add_action( ‘template_redirect’, ‘my_login_redirect’ );
What the above code does is listen to the parameter custom_welcome_page in the url, if it is found then it will try to redirect the user. To determine the page, we write another function that takes the membership level of the user and returns the appropriate url.
[php]function my_member_welcome_pages( $role ){
// Set the welcome pages in the following array
$welcome_pages = array( ‘subscriber’ => ‘http://www.yourfabulousmembershipsite.com/subscriber-welcome/’, ‘s2member_level1’ => ‘http://www.yourfabulousmembershipsite.com/level1-welcome/’, ‘s2member_level2’ => ‘http://www.yourfabulousmembershipsite.com/level2-welcome/’
if( $welcome_pages[$role] ){ return $welcome_pages[$role]; } else { return ‘http://www.yourfabulousmembershipsite.com/your_default_welcome_page/’; } }
These functions are the basic functionality needed to create your own custom welcome page redirects for your members.
Would you like to have a plugin with a simple user interface that does this for you? Drop me a line.
While working on a membership site I wanted to retrieve a user’s role by their user id, but I couldn’t find a quick function to do this. WordPress does provide the WP_User object which gives us quick access to all user information, including user roles. To get the user role by a given ID we can do the following in php:
[php]
function get_user_roles( $id ) {
$user = new WP_User( $user_id ); // this gives us access to all the useful methods and properties for this user
if ( $user ) { $roles = $user->roles; // returns an array of roles return $roles; } else { return false;
}
}
[/php]
It’s useful to note that it’s possible for a user to have multiple roles, even though most sites and plugins don’t utilize this possibility. What if you want to check if a user has a certain role? We can write a simple function for that as well. In my case I wanted to check if they have the custom role of teacher (a conditional function).
[php] function user_has_role( $id, $role = ‘teacher’ ){ $roles = get_user_roles( $id ); // retrieves an array of roles if ( $roles && in_array ( $role, $roles ) ) { // checks if specified role is listed return true; } else { return false; } }
[/php]
Since WordPress 3.3 a nice new drag and drop uploader was included. It works great because it has fallbacks for older browsers that don’t support the newer HTML5 api. Accessing the file uploader still requires bringing up the media uploader via the upload button. Wouldn’t it be even nicer if we could directly drag and drop our files into our WYSIWYG editor?
The newish wp_editor function also makes it easy to include additional tinymce editors for our plugins and themes. I was looking for a way to add the tinymce editor to P2 and include a quicker way to drag and drop files. Adding the editor is relatively easy now but and it even lets you add the media upload button to the front end, but I want to remove the need for clicking that button.
Possible solutions:
My first thought was to insert the new native uploader inline below the editor so that we could directly drop files into a dropzone without having to navigate to the media uploader. I’m sure it can be done, but it was going to take me too long to do it properly and cleanly.
My second idea was to look for existing plugins that could do all the work, but there don’t seem to be any functional ones in existence that are straightforward to implement and integrate. It also seems a bit overkill to include another uploader when WordPress already can do everything I need.
After that I thought about digging into the filereader api for HTML5 and making my own solution…but then I thought of a shortcut that would be the best of all worlds.
Providing you have the upload buttons enabled for your editor, it’s possible to detect a drag event when a file is being dragged into the editor and automatically fire the native media uploader.
The great thing about this is:
- It streamlines the uploading process without adding loading scripts unnecessarily.
- It removes one mouse click operation and feels more intuitive than navigating to the uploader manually.
- It relies on the native uploader which deals with all the complex stuff, such as fallbacks, inserting the file into the post, setting parameters, attaching the file to the post and so forth. No reinventing the wheel!
- It removes the need for a separate ‘drop zone’, which takes up space. Instead, the editor itself is the drop zone.
Implementation:
All we need is a few lines of javascript. What is needed:
– A way of detecting when a file is dragged into our editor that works across all modern browsers
– The id attribute of our editor
– A trigger event to activate the native uploader when a file drag (or drop) is detected. For this we need to know how to select the media upload button with a selector.
optional:
some extra magic to add some css styling during the drag and drop operation.
Part 2 will cover the actual code…which I haven’t written up yet. Want to see the final solution? Sign up to the newsletter and you’ll get a notification when it is published.
There’s a number of ways to retrieve the post id of a post, but what if your page has multiple loops and you want to retrieve the main post id of the page? In my case I wanted to insert social buttons only on the main content of the page. If you are using the_content filter to add the html for your social buttons, it will show every time any kind of post content is displayed. Some page designs often use several loops to display various pieces of content (especially front pages), so you could end up with an abundance of social buttons – not exactly ideal. My solution then involved checking to see if the currently outputted content was the main content of the page by comparing post ids.
So I looked to see if there was a simple way to access the main post id – even if we are inside a secondary loop. Surprisingly, there doesn’t really seem to be a function for this. The closest thing is a function called get_page_by_path, but that works just for pages. Another idea is to access the $wp_query global variable, but this can be altered when other queries are made. What we can do is store the ID in our global variable when we are certain that $wp_query contains the main post id.
[php] function main_post_id() { global $wp_query; global $main_post_id; if( is_singular () ) { // ignores index pages for posts, categories, tags, archives etc $main_post_id = $wp_query->post->ID; } } add_action( ‘wp_head’,’main_post_id’ );
[/php]
Now we can quickly access the post id anywhere on the page, even if you are in a custom loop.
[php]