Never miss a thing!

Sign up to have the latest news and announcements from my site delivered straight to your inbox.
  • This field is for validation purposes and should be left unchanged.

Reader Interactions

Comments

  1. I do a lot of these, but learned something new about the color editor, thanks!
    Some of the CSS I only comment out, like Woo Commerce, in case someone comes back and decides they actually do want it!

  2. Phew! Makes me feel better I’m not the only one who wants to clean up the un-used portions of CSS. Never even considered disabling editors, but then again, I haven’t had a client TRY that yet . . .LOL. Will disable the editors from now on!

    • I once had a client accidentally stumble into the editor and save some random bit of whatever text was on the clipboard. They swore they didn’t know how it happened….

  3. Thanks for the great tips, Coach C 🙂

    Question: As you’ve shown for the specific file locations and edits, will these golden snippets will get over-written when WordPress and/or framework/theme/child-themes update? Thanks again.

    • Hey Steve! Your wp-config.php file is never overwritten in a WordPress update (WordPress has a file called wp-config-sample.php that gets manually changed to wp-config.php when setting up your site).

      The other places you’d make these changes (i.e. your child theme) would definitely get overwritten on an update. That’s why I like Genesis – you can update it all you want, but it doesn’t mess with your child theme code. Once you customize any theme, you shouldn’t ever update it automatically.

  4. Often you hear people complain about themes and plugins including functionality that you don’t need. But that’s the beauty of WordPress, as long as the theme is coded correctly you should be able to remove anything you don’t need and fully customize it via a child theme or plugin 😉

  5. I usually do the following:

    Kill the editors. Kill most of the stuff on the dashboard. Most of my clients don’t need anything but the stuff that’s actually relevant to their sites, so all the news feeds go away. Disable the rich editor for the user that does the content managing if the user is blind. The rich editor is accessible, but people seem to have a lot of trouble with it, so I kill it for them and they can turn it back on if they want to use it. Unhook the customizer, especially if there’s a custom theme involved. There’s been a lot of time spent on creating an accessible child theme, or customizing one that’s pre-made so that it’s accessible, so I don’t want the client going in to the customizer, finding the shinies, and then playing with colors, only to break color contrast. In some cases, hiding the permalinks settings with a custom functionality plugin. This is usually for multisites that are using subfolders instead of subdomains. in some cases, I don’t get to make the subfolders VS. subdomains/domain mapping decision, so once things are configured, I hide the permalinks from all but the support user, (me) so that they can’t be easily tampered with.

    • Interesting point about accessibility in the rich editor. I hadn’t thought of that.

      Do screen readers literally read HTML input in the text editor mode or just say things like “bold” or “end bold”?

  6. Hey Amanda,

    Do you do this by simply altering the user-roles of your client? Seems like that would be the quickest way instead of un-hooking things just give your client a custom user-role with what they can and can’t do 😉

  7. For someone learning and continuing to advance their understanding of PHP, CSS, Genesis and WordPress etc. This is invaluable stuff! It’s always great to hear your tips and advice Carrie. Thanks for continuing to share your experience and knowledge with us wannabe developers!

    • Hey Neil,
      Thanks so much for the kind words! I read so many blog posts as I was learning this stuff (and still do), that I hope to return the favor to others with my site. 🙂

      Cheers,
      Carrie

  8. Carrie, do you make all your adjustments in a ServerPress blueprint and then use the same thing for each new build? I would imagine that would be the thing to do. I know with the iThemes Security Theme we can turn of the editor

  9. Usually I remove all the unused widgets, makes that screen much more understandable for the editors. Apart from that on all sites I manage I give users a sightly modified ‘editor’ role (using the members plugin) and install ‘Simple History’ so no more “I did not do anything”.
    So far nobody complains about not being able to ‘play’ with plugins etc.

  10. Great ideas, Carrie! I am loving the discussion in the comments too.

    We always install a custom plugin that removes the clutter on the dashboard home page. We also have a custom editor role that removes access to the dashboard menus for Genesis, Profile, Plugins, Users, Tools, and Settings but allows access to Menus, Widgets, and Gravity Forms.

    Our small business clients seem to be able to do do what they need to and have never asked for more access.

  11. Hey Carrie, thought I would come in and play the devils advocate here. In fact I am just tweaking a presentation for WC Seattle which is focused on beginners and mine is about the dashboard. In fact in one slide I address this.

    I would say in most cases this is totally understandable and best practice for devs. But I will also say I have had a lot of people come to me having been dumped by their dev, and frustrated because options that they have researched and found that should be there aren’t. Now I understand, again, why it’s done. And often it’s scary to think of them having access but at the same time it can be very frustrating to the user when they need to hire someone to either explain what has happened, or even fix it for them.

    So my question would be. If at a point, a person is no longer managing the site for that client, should they tell them what has been done, why it’s been done, or is that opening a can of worms. Again, I am coming in from the other perspective here 🙂

    And if I don’t come back in tonight, I do really have to finish my presentation 🙂

    • Ha! I always appreciate views from the dark side. 😉

      This goes back to client education. Let your client know that you’ve (activated a plugin, or done stuff in the theme) to make the admin experience better for them. But then provide them an exit strategy if they need it. I typically do this by providing a separate admin login from their main account that has full admin access. Of course, on a site with a lot of users, you might need a different strategy.

      Bottom line: I can completely understand the confusion/frustration that could cause users.

  12. I just knew you would have the perfect answer 🙂 And education is key… if we could get all devs to think this way. Of course, I’m talking about a perfect world. cheers Carrie!!

  13. In the text editor, screen readers will read the literal input. The only thing they may not read is punctuation symbols, so I usually keep mine set to “some” as opposed to “all” or “no” punctuation. When I’m coding, I need the punction to all be read, because syntax errors happen if it’s not. You can set voice profiles for different applications, but not different webpages. So for Internet Explorer, I use my normal “some” profile. Typing markup is second nature for me, so I can usually type it without thinking. I’ll go back through and check everything just in case though.Enter your comment here…

  14. Hey AJ,

    I probably should have been more clear about that. Yeah, they get a specific user role. This is probably the only time I’d say WordPress needs to borrow something directly from Drupal. User roles and management. I’d love to have complete granular control over assigning capabilities to users.

Trackbacks

Leave a Reply