Posts Tagged ‘WordPress’
Just look on the list of security issues which WordPress 3.5.1. release addresses:
- A server-side request forgery vulnerability and remote port scanning using pingbacks. This vulnerability, which could potentially be used to expose information and compromise a site, affects all previous WordPress versions.
- Two instances of cross-site scripting via shortcodes and post content.
- A cross-site scripting vulnerability in the external library Plupload.
Are you still waiting? Go-go-go! Go to your WordPress update center, and press update button. Do not forget to make files and database backup before update, of course.
Detailed information is available at WordPress News page.
Existing WordPress permissions system doesn’t allow to realize such model. Yes, WordPress prohibits author to edit or delete posts and items of other authors, but she still see all that stuff. It’s slightly inconvenient, isn’t it?
“View Own Posts Media Only” WordPress plugin includes a set of useful hacks (don’t panic that’s just a legal code snippets, nothing from the dark territory of hackers, crackers and other malware manufactures) to offer you desired features, I wrote above.
Is your WordPress blog opened for new user registrations? If “YES”, then you are familiar with a lot of users registered every day. But the most of those users do not login, do not make posts. It seems that there are no real users behind such registrations. All these contacts like:
- “yqvcevsjc (email@example.com)”,
- “ymmoncmn7 (firstname.lastname@example.org)”,
- “www.cheap-some-best-and-beautiful-garbage.com (email@example.com)”, etc.
are SPAM registrations obviously. These fake users at WordPress database cost you a time to delete them, create the mess from your lovely users list, so you (and me together with you) have strong desire to Stop SPAM registrations. Do You?
Any site owner asks himself, how can I make my site lighter and faster. What else should I do? What technique to apply? General site speed is critical property for present days. As there are a lot of alternative variants where web-surfer may find and get the same information, large part of visitors do not wait, while their browsers finish download process of slow page. They just return to search engine and click on the next link from the huge list of available sources. This way, we (site owners) lose auditory and, as a result, have a lower traffic. And WordPress blogs are not exclusion. The same general rools are in action for our loving WordPress too. It doesn’t matter, what platform do you use, in order to build your site. It does matter, with what speed your platform delivers content to your site’s visitors.
Reliable hosting service provider; fast and powerful server; wide, high-speed, broadband, backbone channel; popular and effective publishing platform – all of these factors are important and valuable in relation to the final result – your site speed.
Trying to build the list of recently viewed posts I added simple tracking code into my active “Twenty Eleven” theme
single.phptemplate 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?
‘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.