Improving Ease of Use with the WordPress Admin
•Download as KEY, PDF•
0 likes•1,133 views
Presentation for WordCamp Cape Town 2011
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Improving Ease of Use with the WordPress Admin
- 1. IMPROVING EASE OF USE WITH WORDPRESS ADMIN DASHBOARD
- 2. OVERVIEW
- 4. OVERVIEW 1. User Roles. 2. The Login Screen.
- 5. OVERVIEW 1. User Roles. 2. The Login Screen. 3. The Dashboard.
- 6. OVERVIEW 1. User Roles. 2. The Login Screen. 3. The Dashboard. 4. The Content Editor.
- 7. OVERVIEW 1. User Roles. 2. The Login Screen. 3. The Dashboard. 4. The Content Editor. 5. Other
- 8. USER ROLES - Create a “clean” admin account - Set-up the main user as an editor - Use the current_user_can() function: if ( !current_user_can( 'administrator' ) ) { //do something awesome here }
- 10. THE LOGIN SCREEN Hook: login_head
- 12. THE DASHBOARD Tidy up... - Does the client need this item?
- 13. THE DASHBOARD Tidy up... - Does the client need this item? - Will the client use this item?
- 14. THE DASHBOARD Tidy up... - Does the client need this item? - Will the client use this item? - Is this item an enhancement?
- 15. THE DASHBOARD
- 17. THE DASHBOARD Hook: wp_dashboard_setup // Globalise the Meta Box Widgets Array global $wp_meta_boxes; unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_right_now']);
- 18. THE DASHBOARD
- 19. THE DASHBOARD
- 20. THE DASHBOARD
- 21. THE DASHBOARD Hook: admin_menu
- 22. THE DASHBOARD Hook: admin_menu // Globalise the Menu Array global $menu; ... unset( $menu[key($menu)] ); ...
- 23. THE DASHBOARD
- 24. THE DASHBOARD // Add Theme Editing Capabilities $role_object = get_role( 'editor' ); $role_object->add_cap( 'edit_theme_options' );
- 25. THE DASHBOARD
- 26. THE DASHBOARD Hook: admin_head
- 27. THE DASHBOARD Hook: admin_head // Globalise the Submenu Array global $submenu; ... unset( $submenu['themes.php'][7] ); ...
- 30. THE CONTENT EDITOR Hook: admin_head
- 31. THE CONTENT EDITOR Hook: admin_head ... <style> #edit-slug-box strong, #sample-permalink, #edit-slug-buttons {display:none;} </style> ...
- 35. THE CONTENT EDITOR Hook: tiny_mce_before_init
- 36. THE CONTENT EDITOR Hook: tiny_mce_before_init // Force paste as plain text ... $init['oninit'] = 'setPlainText';
- 40. THE CONTENT EDITOR Hook: admin_init
- 41. THE CONTENT EDITOR Hook: admin_init // Add custom meta box add_meta_box( $id, $title, $callback, ... );
- 44. THE CONTENT EDITOR // render any shortcode and convert new lines to break nl2br( $string ) # retains line breaks do_shortcode( $content ) # applies any shortcode(s) in $content ... $meta = nl2br( get_post_meta( $postid, $field, $single = true ) ); return do_shortcode($meta); ...
- 47. THE CONTENT EDITOR Filter: widget_text
- 48. THE CONTENT EDITOR Filter: widget_text // render any shortcode in widgets. add_filter('widget_text', 'do_shortcode');
- 50. OTHER CONSIDERATIONS Allow for Errors <a href="facebook.com">Facebook</a> <!-- Will return an error --> // http://www.facebook.com, www.facebook.com, facebook.com will all work. if( strpos( $url, 'http://' ) === false ) return 'http://' . $url; else return $url ...
- 51. OTHER CONSIDERATIONS Allow for Errors <a href="facebook.com">Facebook</a> <!-- Will return an error --> // http://www.facebook.com, www.facebook.com, facebook.com will all work. if( strpos( $url, 'http://' ) === false ) return 'http://' . $url; else return $url ... Consider creating a plugin
- 52. CONCLUSION
- 53. CONCLUSION If it is difficult to update, it won’t get updated.
- 55. ~fin.
Editor's Notes
- As developers we sometimes forget that just because a system like WordPress makes updating a site infinitely more easy for us, it can still be alien to the end user.\n\nIn an ideal world, our clients and customers would understand basic html, be able to assign classes to paragraphs and always apply the correct ones, they will know how to crop and edit images, and know how to correctly apply header tags. \n\nMost importantly, they will stop at this, and never learn any other coding thus leaving a big demand for us as developers. \n\nIn the real world however, our clients vary between users who don't know how to get online if the 'big blue E thingy' is deleted from their desktops and use google to type URL&#x2019;s, through to those that are comfortable using a PC, through to clients who have used WordPress before, can find their way around and are happy adding and editing content. In addition, we need to consider ease of use for users. However technically adept you are, realistically, you are not going to update your site regularly if its an overly-complex procedure.\n
- We can break the user's backend experience down into five elements.&#xA0;\n\nThe role of user.\nTheir first point of contact; The login screen.\nThe first thing they encounter once logged in; The dashboard (and menus).\nThe main task they will be doing; Adding and editing content.\nWe will end with other considerations we need to make.\n
- We can break the user's backend experience down into five elements.&#xA0;\n\nThe role of user.\nTheir first point of contact; The login screen.\nThe first thing they encounter once logged in; The dashboard (and menus).\nThe main task they will be doing; Adding and editing content.\nWe will end with other considerations we need to make.\n
- We can break the user's backend experience down into five elements.&#xA0;\n\nThe role of user.\nTheir first point of contact; The login screen.\nThe first thing they encounter once logged in; The dashboard (and menus).\nThe main task they will be doing; Adding and editing content.\nWe will end with other considerations we need to make.\n
- We can break the user's backend experience down into five elements.&#xA0;\n\nThe role of user.\nTheir first point of contact; The login screen.\nThe first thing they encounter once logged in; The dashboard (and menus).\nThe main task they will be doing; Adding and editing content.\nWe will end with other considerations we need to make.\n
- We can break the user's backend experience down into five elements.&#xA0;\n\nThe role of user.\nTheir first point of contact; The login screen.\nThe first thing they encounter once logged in; The dashboard (and menus).\nThe main task they will be doing; Adding and editing content.\nWe will end with other considerations we need to make.\n
- As a starting point, we can provide the client with an admin login to keep hold of in case they decide to use another developer in the future, or we get run over by a bus.&#xA0;\n\nWe will leave that admin backend alone for our/or another developer&#x2019;s use and set our current user up as an editor.&#xA0;\n\nAs such we will wrap any of our custom backend functions with the current_user_can() function and we will use it so that the function will only apply if the user is not an administrator\n
- Changing the login screen logo is a very simple process, but still worth considering. After all, as developers its familiar to us, but if you are logging into your website for the first time having never seen WordPress before, anything familiar to hold on to will help, so why not help that first time user out by adding their logo to the login screen. At the very least, they now know they're in the right place. To do this we add an action to the&#xA0;login_head hook that adds some custom css that displays the logo.\n\nNote that we won't use the current_user_can() function here as at this point, the user obviously isn't logged in!\n
- Having eased the client into the backend with a nice friendly login screen, the last thing you want to do is terrify them with a page cluttered with info they don't need.\nTidy up the dashboard \nLook at the items on the dashboard, and ask yourself:\n\n1. Does my client need any of these,&#xA0;\n2. Will they make use of them,&#xA0;\n3. Do they enhance the backend.&#xA0;\n\nShould the answer to these questions be a resounding 'no', then we need to tidy the dashboard up. Obviously we can remove all the visible items via the screen options, but these only apply on a user by user basis. If your client will be adding users, you may want to consider de-registering some, or all, of the dashboard widgets. \n\nThis probably doesn't come under the realms of 'best practice' as we are taking away the clients choice, but for the purposes of the presentation, we will assume that the client:\n\nA. wants to be spoon-fed with only what they need.&#xA0;\nB. The client wants a fairly static site, with no commenting.\nC. Has no interest in incoming links.\nD. Gets frightened by technical terminology and the word 'plugin' scares them.\nE. The client may add new users from time to time and the layout for their dashboard must be the same\n&#xA0;\n\n\n
- Having eased the client into the backend with a nice friendly login screen, the last thing you want to do is terrify them with a page cluttered with info they don't need.\nTidy up the dashboard \nLook at the items on the dashboard, and ask yourself:\n\n1. Does my client need any of these,&#xA0;\n2. Will they make use of them,&#xA0;\n3. Do they enhance the backend.&#xA0;\n\nShould the answer to these questions be a resounding 'no', then we need to tidy the dashboard up. Obviously we can remove all the visible items via the screen options, but these only apply on a user by user basis. If your client will be adding users, you may want to consider de-registering some, or all, of the dashboard widgets. \n\nThis probably doesn't come under the realms of 'best practice' as we are taking away the clients choice, but for the purposes of the presentation, we will assume that the client:\n\nA. wants to be spoon-fed with only what they need.&#xA0;\nB. The client wants a fairly static site, with no commenting.\nC. Has no interest in incoming links.\nD. Gets frightened by technical terminology and the word 'plugin' scares them.\nE. The client may add new users from time to time and the layout for their dashboard must be the same\n&#xA0;\n\n\n
- Having eased the client into the backend with a nice friendly login screen, the last thing you want to do is terrify them with a page cluttered with info they don't need.\nTidy up the dashboard \nLook at the items on the dashboard, and ask yourself:\n\n1. Does my client need any of these,&#xA0;\n2. Will they make use of them,&#xA0;\n3. Do they enhance the backend.&#xA0;\n\nShould the answer to these questions be a resounding 'no', then we need to tidy the dashboard up. Obviously we can remove all the visible items via the screen options, but these only apply on a user by user basis. If your client will be adding users, you may want to consider de-registering some, or all, of the dashboard widgets. \n\nThis probably doesn't come under the realms of 'best practice' as we are taking away the clients choice, but for the purposes of the presentation, we will assume that the client:\n\nA. wants to be spoon-fed with only what they need.&#xA0;\nB. The client wants a fairly static site, with no commenting.\nC. Has no interest in incoming links.\nD. Gets frightened by technical terminology and the word 'plugin' scares them.\nE. The client may add new users from time to time and the layout for their dashboard must be the same\n&#xA0;\n\n\n
- as such we will remove the following widgets:\n\n1. Incoming links\n2. Recent Comments\n3. Plugins\n4. Primary Dashboard (WordPress Blog)\n5. Secondary Dashboard (Other WordPress News)\n\nWe can do this by hooking onto the wp_dashboard_setup hook, globalising the $wp_meta_boxes array and unsetting the elements we don't want leaving us with a cleaner dashboard\n
- as such we will remove the following widgets:\n\n1. Incoming links\n2. Recent Comments\n3. Plugins\n4. Primary Dashboard (WordPress Blog)\n5. Secondary Dashboard (Other WordPress News)\n\nWe can do this by hooking onto the wp_dashboard_setup hook, globalising the $wp_meta_boxes array and unsetting the elements we don't want leaving us with a cleaner dashboard\n
- This leaves us with a completely blank dashboard, so now we need to add something there.&#xA0;\n\nLets add a welcome message to ease the client into the world of the WordPress backend.&#xA0;\n\nFor the welcome screen we can explain the basic pages and provide links to further explanations on the WordPress codex site.&#xA0;\n\nThis is all clearly explained in the standard 'Help' drop-down, but we can tailor our welcome screen to the exact content of the site, and to go the extra mile, we can include a contact form so they can mail any questions straight to us.&#xA0;\n\nIf you're feeling particularly user friendly, you could even answer some of the mails!\n
- Now the dashboard is slimmed down and friendly, we can look at the menus.\n\nNearly all of the more basic sites I've built don't make use of commenting at all, nor do they have a use for the links menu.&#xA0;\n\nWe will assume the same for this site as well as deciding that the Press This app in the Tools menu is also no good to our client.&#xA0;\n
- As such, we can hide the Comments, Links and Tools menus by hooking into the admin_menu action, accessing the menu array and unsetting them.\n
- As such, we can hide the Comments, Links and Tools menus by hooking into the admin_menu action, accessing the menu array and unsetting them.\n
- In addition to removing unwanted menus, we can also add in any that we might need that would otherwise be hidden by default. For example, the client may well want to be able to add menu items. This would not be possible using a normal editor user role, but we can work around this by adding capabilities to the editor user role.\n
- However, lets prevent them from editing widgets as these can be quite fiddly and easy to make a mess of.&#xA0;\n\nWe can do this by adding to the admin_head hook and unsetting the correct item in the $submenu array\n\nOur dashboard is now complete, friendly, efficient and we're ready to start posting content.\n
- However, lets prevent them from editing widgets as these can be quite fiddly and easy to make a mess of.&#xA0;\n\nWe can do this by adding to the admin_head hook and unsetting the correct item in the $submenu array\n\nOur dashboard is now complete, friendly, efficient and we're ready to start posting content.\n
- We an start by removing any unnecessary elements, as we did with the dashboard.\n\nFor our client, the permalink isn't going to be an issue.&#xA0;\n\nThere will probably be the odd verbose title, but if they become concerned with SEO, they can give the admin login to their SEO guru and carry on as normal.&#xA0;\n\n&#xA0; \n
- To do this, we add an action to the admin_head hook and add a display: none style to any elements we want to remove.\n&#xA0; \n
- To do this, we add an action to the admin_head hook and add a display: none style to any elements we want to remove.\n&#xA0; \n
- I also find that Post Tags are irrelevant for a lot of smaller sites. These are normally displayed by default on the post editor, so lets remove them as we don't need them.\n&#xA0;\nFor the purposes of the demo, I've used the remove_meta_box() function to completely irradicate post tags. I would recommend against this though.&#xA0;\n\nBest practice would be to set up an options page for site admins which gives them the option to over-ride this setting.&#xA0;\n\nIf you were feeling particularly clever, you could let them toggle it on a user by user basis.\n\nNow the post editor page is looking tidy we can focus on the editor itself. The TinyMCE editor has been around a while, and is pretty user friendly with one exception - pasting content from Word\n&#xA0; \n
- Yes there is a post from word button, yes there is a post as plain text button and yes there is a clean up formatting button, but no the client is not going to remember to use them. At best they will remember most of the time and hate you all of the time for adding yet another process to their day.&#xA0;\n\n\n&#xA0; \n
- Fortunately, we can resolve this by&#xA0;hooking into the tiny_mce_before_init() function and adding a function of our own that forces all pasted text to be pasted as plain text. Now the client can paste from Word to their heart's desire.\n&#xA0; \n
- Fortunately, we can resolve this by&#xA0;hooking into the tiny_mce_before_init() function and adding a function of our own that forces all pasted text to be pasted as plain text. Now the client can paste from Word to their heart's desire.\n&#xA0; \n
- To further assist the client in their posting, we can make use of the shortcode, an incredibly powerful tool. As a really basic example, consider email addresses. Yes, there is a hyperlink button in the tinyMCE editor, but the average user won't necessarily know how to utilise this to link email addresses. The addition of a simple shortcode will allow the user to wrap any email address with the relevant short code in the backend and for the address to rendered as a link in the frontend. This is a very simple example, but there are tons of other shortcodes you can write.\n
- Ok, so we've built our clever shortcode, but 5 minutes after you've demo'ed the site, the client has forgetten if they need to write e or email for the email address shortcode and your clever shortcode is going to waste. To really show-off (and I have to confess I got this idea from using the Canvas framework), we can add our shortcodes to the tinyMCE toolbar. There's a page in the WordPress codex about adding buttons to the tinyMCE toolbar, and you'll need to do a bit of reading up on tinyMCE, but its a relatively straightforward process. You can reference the source code in the demo plugin as a starting point.\n
- So now our content area is clean, free of evil Microsoft editing and easy to add our shortcode to. However, our client needs to add some custom post meta to each post. Fortunately, the ever-flexible WordPress backend allows us to easily add our own user friendly custom post boxes. The WordPress codex gives a simple example of using the add_meta_box() function, which I've used for the demo, but there are plenty of great tutorials out there providing far more flexible examples.\n
- So now our content area is clean, free of evil Microsoft editing and easy to add our shortcode to. However, our client needs to add some custom post meta to each post. Fortunately, the ever-flexible WordPress backend allows us to easily add our own user friendly custom post boxes. The WordPress codex gives a simple example of using the add_meta_box() function, which I've used for the demo, but there are plenty of great tutorials out there providing far more flexible examples.\n
- One thing to consider however is that if our client decides to make use of his email shortcode in the post meta, and &#xA0;wants to retain the line breaks he's added, this is what will be displayed...\n
- as you can see, our shortcode isn't rendering and the line breaks are gone.\n
- Luckily we can write a small function that adds the php nl2br function and renders the content as a shortcode (where necessary)\n
- and now our content is rendering correctly\n
- Just in case we allow our client to edit widgets in the future, or if we as admins want to use the shortcodes we've created, its also worth adding a filter to apply the do_shortcode function to widget_text. This will allow for shortcodes to render in sidebar text widgets as well.\n\nOur content area is now clean and tidy, relatively fool-proof and word-proof!\n
- Just in case we allow our client to edit widgets in the future, or if we as admins want to use the shortcodes we've created, its also worth adding a filter to apply the do_shortcode function to widget_text. This will allow for shortcodes to render in sidebar text widgets as well.\n\nOur content area is now clean and tidy, relatively fool-proof and word-proof!\n
- Now the dashboard and content areas are looking good, we can add a few more features to add the icing to the cake.\n\nFirstly, most companies want their contact details on display and often in sidebars and footers.&#xA0;\n\nIt makes sense then to create a custom page in the backend to capture these details rather than hard-coding them into the theme.&#xA0;\n
- With any information the site editor adds, we need to allow for error. Never assume that the information entered is correct. Obviously for things like post content, its not a problem, but for specific content like URLs, prices, sizes it will be\n\nFor example, if we are going to display a facebook button that links to the URL supplied for the facebook page, consider that the site editor may omit the http:// prefix\n\nfortunately we can run the URL through a simple function that adds the prefix in should it be needed\n\nAs a closing point, I would recommend adding these functions, hooks, filters and shortcodes to a plugin, you can go with an mu-plugin or a straight plugin, the choice is yours.&#xA0;\n\nFor you as a developer it means you can simply apply your plugin to every site of this nature that you build, and for the client, it means they aren't tied to any one theme. Using our email shortcode as an example, if the user changes theme, their nicely rendered email addresses are now plain text with and e on each side.\n\n&#xA0;As a further example, if you apply the wp-touch plugin to your client's site, it will render a mobile version of your site using a separate theme this will also result in shortcodes no longer rendering.\n
- It can be fairly tedious to spend time messing around with backend. It all works fine out of the box, WordPress have spent years developing code, so why can't the client pull their finger out and learn some new tricks. In reality, your beautifully built site will become redundant if the client can't update it easily. Worse still, they may end up ditching WordPress altogether and paying a cowboy to build a site with Frontpage that they then update once a month at exorbitant prices.&#xA0;\n
- Some of the suggestions I have made seem pretty innoccuous, but most have made a big difference to clients I have encountered in the past. If turning the backend pink and embedding pictures of fluffy animals everywhere is going to mean a regularly updated site, then this is just as important as ensuring the site looks and works great for the site visitor.\n