CSS pseudo element for caret in WordPress Advanced Sidebar Menu

I have been using the fantastic Advanced Sidebar Menu for WordPress – a plugin which gives you configurable widgets which automatically generate a sidebar menu. However, out of the box, the free version lacks (CSS) style – most importantly, some way to indicate whether a menu item is selected and/or has sub-items.

Luckily it provides plentiful classes to attach your styles to – in particular, all you need to tell whether an item is open or not. Combine this with the elegantly simple CSS only technique to generate a caret and you can easily create a simple menu like this (working example on History of Medical Sciences website)

AdvancedSideBarMenu

Basic styling

Three styles give me the simple look I wanted:

ul.child-sidebar-menu{
 padding-left:0; /*stop browser indenting too far*/
 }
ul.child-sidebar-menu li{
 list-style:none; /*get rid of bullets*/
 }
ul.child-sidebar-menu li>a{
 color:#777; /*make text a laid-back grey*/
 }

Active menu item

To indicate the currently active item, the developers have given us the

current_page_item

class which is used like this:

ul.child-sidebar-menu li.current_page_item>a{
 font-weight: 700; /*bold for <a> children of the active list item*/
 }

Has item got children

The developers attach a

has_children

class to items with children. We can pick this up and use the magic of CSS pseudo classes to add a right-pointing caret after every link that has children.

li.has_children>a::after{
	width: 0px; 
	height: 0px; 
	border-top: 5px solid transparent;
	border-bottom: 5px solid transparent;
	border-left: 5px solid #d1dee4;
	content:"";
	position: absolute; /*to prevent it picking up the height of the <a> that is before it*/
	margin-left: 5px; /*now it's absolutely positioned, we need to add suitable margins (not padding which would change its shape)
	margin-top: 5px;
}

However, in big menus, it’s nice to see when an item is open. Again, the developers have given us a class to achieve this:

current_page_ancestor

.

li.current_page_ancestor>a::after{
	border-right: 5px solid transparent;
	border-left: 5px solid transparent;
	border-top: 5px solid #d1dee4;
	margin-top: 8px; /*adjust margin to make caret look as if it has rotated*/
}

But this will only show a down caret on the parent if one of the children is selected. To show it as soon as you can see its children (ie when the parent is selected), we need to add an additional selector as follows:

li.current_page_ancestor>a::after, li.has_children.current_page_item>a::after{
	border-right: 5px solid transparent;
	border-left: 5px solid transparent;
	border-top: 5px solid #d1dee4;
	margin-top: 8px;
}

MSDLT Update May-Oct 2013

Teaching Excellence Project Award for mobile technology

New user-friendly interface for My Workspace Resources for Biomedical Sciences students in Sakai/WebLearn

Bringing Biochemistry TLTP software up to date

And progress with: online maths assessment; project choosing; clinical sign-off and the History of Medical Sciences website

Get your copy here: ETSGMSDLTNewsMaytoOct2013.

WordPress: Improvement to Form Manager plugin when used with Members plugin

As mentioned in my earlier post, the WordPress Form Manager and Member’s plugins integrate fantastically. However, one thing that didn’t quite perfectly was that if a user was allowed to view the submission data for forms (the ‘

This is because, by default, clicking on the name of a form takes you to the edit/design page, whether or not you are allowed to edit the form. Therefore, if you are not allowed to edit the form, it doesn’t show the page, and you see nothing except the tabs for the actions that you are allowed to access, in this case the “Submission Data” tab. To see the submission data, you then have to click on this tab to view the data. Obviously, this second click is annoying, and the blank page is ugly/confusing.

Thankfully, this issue was quite easy to fix, by replacing line 155 of wordpress-form-manager/pages/main.php with the following code:

<strong>
   <?php if(!$fm_MEMBERS_EXISTS || current_user_can('form_manager_forms') || current_user_can('form_manager_data')) { ?>
      <a class="row-title" href="<?php
      //If the user can edit forms, take them to the edit page, as usual
      if(!$fm_MEMBERS_EXISTS || current_user_can('form_manager_forms')) { 
         echo get_admin_url(null, 'admin.php')."?page=fm-edit-form&sec=design&id=".$form['ID'];
      }
      //Otherwise, if the user can view the data, take them to the data page
      else if(current_user_can('form_manager_data')) { 
         echo get_admin_url(null, 'admin.php')."?page=fm-edit-form&sec=data&id=".$form['ID'];
      }
   ?>"><?php echo $form['title'];?></a>
   <?php } 
   //If user has no form permissions, do not create a link
   else { 
      echo $form['title']; 
   }  ?>
</strong>

Basically this just means that:

  • If the Members plugin isn’t installed, the link goes to the edit/design page
  • If the user can edit forms, the link goes to the edit/design page
  • If the user can’t edit forms but can view data, the link goes to the submission data page
  • If the user can’t edit forms or view data (i.e. they can do nothing with individual forms), then the form name isn’t made into a link

I hope this is a robust improvement – it seems to work well for me, and will prevent my ‘view data only’ users from getting annoyed/confused by the form link taking them to the wrong place.

WordPress Form Manager and Members plugins integrate brilliantly

We’ve been working with the WordPress Form Manager plugin for a while, and have found it an excellent and flexible way to create forms in WordPress (thanks Campbell Hoffman). However, I was initially struggling when trying to change the way the permissions worked within the plugin.

By default, only site administrators get to see the forms menu item in the Dashboard, and only they can edit forms, view submission data etc. I wanted to allow other roles (e.g. Contributors) to view submission data, but, ideally, not to edit forms, change advanced form settings etc, or edit posts etc. Therefore, I started looking around in the Form Manager plugin code to see if I could change things to allow different roles to do different things and was getting confused by things like the $fm_MEMBERS_EXISTS variable. What I should have done, as always, is look at the docs for the plugin, where I would have found (and eventually did find) this: http://www.campbellhoffman.com/form-manager-faq/#how-do-i-restrict-access-to-different-parts-of-form-manager-members

It turns out that the Form Manager plugin integrates with Justin Tadlock’s Member’s plugin, which in itself seems like an excellent plugin, allowing you to change the capabilities associated with different roles, create your own roles and more. As an aside, users, roles and capabilities in WordPress can be confusing, but Justin’s post on the what they all mean makes it much less so.

Therefore, combining these two plugins allowed me to create a new role that has very limited capabilities. Alongside the standard ‘read’ capability, all they can do is view the list of available forms (the ‘form_manager_main’ capability), view the submission data table (‘

In conclusion, I would say the Members plugin is a ‘must have’ if you want something other than the standard roles offered by WordPress and the Form Manager plugin, of which I was already a fan, is made all the better thanks to its ability to integrate with Members.

Changing site in WordPress Multisite (e.g. for getting posts from other sites)

I’ve been playing around with WordPress Multisite, and (in some custom plugin code) wanted to be able to get posts from and save posts to a different site to the one that I was in. Thankfully, there are a couple of functions that make this very easy:

switch_to_blog( $id )

restore_current_blog()

What these do is probably fairly self explanatory, but if you give switch_to_blog() the id of a blog, it will switch to that blog. Calling restore_current_blog() with then switch back to the original blog.

For example, to save a post to the current blog, and another blog, you can do the following:

//Post data
$newPost = array(
   'post_title' => 'title',
   'post_content' => 'content',
   'post_status' =>  'publish',
   'post_author' => $userId,
   'post_category' => 'category
);

$postID = wp_insert_post($newPost, false); //Insert post into current blog

switch_to_blog( $otherBlogID ); //Switch to the other blog

$otherPostID = wp_insert_post($newPost, false); //Insert post into other blog

restore_current_blog(); //Switch back to the current blog

Adding an image to a child theme template (e.g. header/footer) in WordPress

Child themes in WordPress are great, because they allow you to modify a theme without making changes to the theme’s core code, which makes things much easier when the theme gets updated – you don’t have to redo all of your changes.

I wanted to add an image to a custom footer template in a child theme (created by copying footer.php from the parent theme). I’d created an images directory in my child theme and put my image there, but was struggling to generate the correct link to the image.

After a bit of searching, I found this suggestion:

<img src="<?php echo get_template_directory_uri(); ?>/images/image.jpg" />

However, this was pointing to the image directory in the parent theme, not the child theme. Further searching led me to this blog: How to load files within WordPress themes, which had the answer (and explains things in more detail):

<img src="<?php echo get_stylesheet_directory_uri(); ?>/images/image.jpg" />

The basic difference, when using a child theme, is this:

  • Template refers to the parent theme
  • Stylesheet refers to the child theme

More information on the get_stylesheet_directory_uri() function can be found here: http://codex.wordpress.org/Function_Reference/get_stylesheet_directory_uri

Note: an alternative is to use the bloginfo() function (echo is not needed), as follows:

<img src="<?php bloginfo('stylesheet_directory'); ?>/images/image.jpg" />

However, it turns out that this is just an indirect way of calling get_stylesheet_directory_uri(), via get_bloginfo() in wp-includes/general-template.php. Both are included in the codex, so I don’t think it really matters which you use.

Another note: Dropping the _uri from the end of the function (i.e. get_stylesheet_directory()), will return the absolute server path to your child theme stylesheet directory, which can be used for including a another php file, e.g.

<?php include( get_stylesheet_directory() . '/includes/myfile.php'); ?>

More on this here: http://codex.wordpress.org/Function_Reference/get_stylesheet_directory