Stop double execution
single.php is called twice for every post view – that was my conclusion after some investigations. How I’ve got it?
Trying to build the list of recently viewed posts I added simple tracking code into my active “Twenty Eleven” theme
template file. After that I’was wondered as I’ve got two records in my log instead the only one after any post view. First valid record for just viewed post and second unexpected record for post, which is chronologically next to the viewed post.
Thus WordPress post content rendered at least twice every time visitor clicks on its permalink. It is obvious and unneeded overhead for my opinion. Why it is happened? How to stop this weird behaviour?
Hide Login is the direct ancestor of the Stealth Login WordPress plugin. Mohammad Hossein Aghanabi (parswp
) tries to give it new life after Stealth Login was removed from WordPress repository as updated last time too long ago. In respect to author of original plugin Mohammad left the comment at the begin of
file: “This is a new version of Stealth Login plugin by skullbit”. Features list is the same. Short description is available here – Stealth Login WordPress Plugin Review
I tested new 2.1 version of Stealth Login, Ups!, excuse me, Hide Login plugin under WordPress 3.4.2. It was a pretty fresh WordPress installation. And I can say that Hide Login WordPress plugin worked well for me, but not too long. I discovered that ‘logout’ slug doesn’t lead to the real logout, just redirects to the home page, while you are still left logged in.
edit-theme-options user capability
‘edit_theme_options’ capability seems to be self-explained. It’s primary purpose is to provide access to WordPress front-end theme options changing.
On practice, if you have ‘edit_theme_options’ capability, then you have access
to the ‘Appearance’ menu at WordPress admin back-end and to its menu items: “Themes” (select a theme for your WordPress front-end) and “Menus” (edit menus supported by your selected theme). Customize theme header image, background color, etc. section and ‘Widgets’ menu items require ‘edit_theme_options’ capability also.
How it is realized? How often and at what places WordPress uses/checks this user capability – ‘edit_theme_options’ in order to decide give current user permission to edit theme options or prohibit access to such functionality? Let’s check this together. We will make a quick look into WordPress version 3.4.2 core source code and comment its related fragments.
Working, working, working… Coding, coding, coding…
Stop! Rest a litle, look around – there is a real life beyond the boring office and amazing, but virtual Internet. Take a minute, book hotels
with a couple of clicks. Fly to old Europe. Rent a car. Visit beautiful historical places. Go for a walk. Sit at the street cafe with a cup of coffee. Enjoy with fresh mountains air and Alps nature. That was my dream for all this year and it will become reality tomorrow. Let me leave you for next 2 weeks. I take a vacation and go to my year 2012 Europe holiday trip: Germany, France, Belgium, Wiesbaden, Constanz, Paris, Mont-Seint-Michel, Gent, Brugge, Frankfurt. Go-go-go!
User Role Editor
User Role Editor
WordPress plugin version 3.8 is published at September 1st, 2012. What’s new?
- Bug fix: Some times URE didn’t show real changes it made to the database. The reason was that direct database update did not invalidate data stored at WordPress cache. Special thanks to Knut Sparhell
for the help with detecting this critical issue.
- WordPress core capabilities are shown separately from capabilities added by plugins and manually.
- If you configured URE to show you ‘Administrator’ role, you will see its capabilities, but you can not exclude any capability from it. I may just add capabilities to the Administrator role now. The reason – Administrator role should have all existing capabilities included.
- Brasilian Portuguese translation is updated.
Published to Pending
What to do if you wish to approve all changes made into published post by their authors? It’s possible by changing post status from ‘Published’ to ‘Pending Review’ automatically. You need just add a piece of code placed below to your current theme
file. It works for users with ‘Author’ role. If you wish to change it, then change ‘author’ in the code to role name you wish to use.
Is that all you need to do? No. You should remove ‘publish_posts’ capability from your users, otherwise user can to publish pending post himself again. Use User Role Editor
plugin for that.
Do you wish to see how does this hack work? Let’s proceed with short video demonstration.
update_core user capability
gives us nothing about update_core capability for WordPress user, except WordPress version of its appearing in the code – 3.0. I suppose according to its name, that
capability is used to decide, if user can update core WordPress file using built-in WordPress upgrade feature or not. What do you think?
Thoughts are just thoughts, while they are not confirmed by practice and strong experiment. Thus, I decided to check this obviouse guess, satisfy my curiosity and investigate, how and for what purpose WordPress uses update_core capability really. Result of my little investigation will be shown to you below.