Ultimate Guide to Roles and Capabilities | Gary Cao. Since Roles and Capabilities are introduced in WordPress 2.0, the User Level approach has been declared deprecated. However, it’s disappointing that a lot of plugins and themes out there still use user levels to control access to admin option pages and other functionalities. This guide shows you how to properly use Roles and Capabilities in your plugins and themes. Note: This article is a long one, therefore you should probably bookmark it so that you can always come back later for reference. Table of Contents What are Roles and Capabilities? As in other CMS and web applications, WordPress has a built-in system to verify whether a particular user has enough privilege to take a certain action.
This system of Roles and Capabilities is much more flexible than User Level, since it enables you to add, remove or reassign capabilities among roles. Capabilities and administration menus As you can see, there’s always a required parameter called capability for each of those functions. WP_Role Class. Settings API. Settings API Languages: English • 日本語 • Português do Brasil • 中文(简体) • (Add your language) Overview The Settings API, added in WordPress 2.7, allows admin pages containing settings forms to be managed semi-automatically.
It lets you define settings pages, sections within those pages and fields within the sections. New settings pages can be registered along with sections and fields inside them. Existing settings pages can also be added to by registering new settings sections or fields inside of them. Organizing registration and validation of fields still requires some effort from developers using the Settings API, but avoids a lot of complex debugging of underlying options management. NOTE: When using the Settings API, the form posts to wp-admin/options.php which provides fairly strict capabilities checking. The functions are found in wp-admin/includes/plugin.php and wp-admin/includes/template.php Function Reference Adding Setting Fields $id - String for use in the 'id' attribute of tags.
$page. Settings API Explained. Update: Plugin Options Starter Kit I have now written a Plugin options starter kit for people who want to learn how to put together a Plugin options form using the WordPress Settings API. You can see more information about the Plugin and download the latest version here. Have fun, and be sure to let me know what other features you want added in future versions! In this post I discuss the WordPress Settings API and how you can leverage them for use in your own plugins. Firstly there is coverage of the API in general and the various functions available together with their usage. After that there is a tutorial section with an example walk through of how to add options to a new sub menu page under the Settings Menu. The Settings API was first added in WordPress 2.7 to make things more efficient when it came to adding options pages for your plugins (and themes) to the WordPress admin area.
Settings API Functions The parameters and what they do are listed next: Drop Down Box Textarea Checkbox. WordPress Settings API Tutorial. Originally posted here: When writing the Simple Facebook Connect plugin, I investigated how the Settings API worked. It’s relatively new to WordPress (introduced in version 2.7), and many things I read said that it was much easier to use.
It is much easier to use in that it makes things nice and secure almost automatically for you. No confusion about nonces or anything along those lines. However, it’s slightly more difficult to use in that there’s very little good documentation for it. Especially for the most common case: Making your own settings page. So, here is my little documentation attempt. Making your own settings page First, add yourself an options page. What this does is quite simple, really: a. Oh wait, we need that function! Hang on a minute, where’s all the options? First, we call settings_fields(‘plugin_options’). Next, we call do_settings_sections(‘plugin’). Defining the settings Here we’ve done three things. Giving WordPress Its Own Directory. Languages: English • Français • 日本語 • Polski • Русский • Português do Brasil • (Add your language) Some people want their WordPress URL to coincide with their website's root (e.g. But they don't want all of the WordPress files cluttering up their root directory.
WordPress allows you to install it into a subdirectory, but have your website served from the website root. As of Version 3.5, Multisite users may use all of the functionality listed below. If you are running a version of WordPress older than 3.5, please update before installing a Multisite WordPress install on a subdirectory. Note to theme/plugin developers: this will not separate your code from WordPress.
Themes and plugins will still reside under wp-content folder. Caveat: Do this at your own risk. Let's say you've installed wordpress at `example.com`. Method I (Without URL change) 1) After Installing the wordpress in root folder, move EVERYTHING from root folder into subdirectory. That's all :) Moving process. WordPress PunBB Complete integration (Page 2) - PunBB 1.3 discussion - PunBB Forums. Revision 16142: /tools/trunk. In Your Language. WPML.
Translating WordPress. Translating WordPress Languages: English • 日本語 • (Add your language) Internationalization and localization (commonly abbreviated as i18n and l10n respectively) are terms used to describe the effort to make WordPress (and other such projects) available in languages other than English, for people from different locales, who use different dialects and local preferences. The process of localizing a program has two steps. The first step is when the program's developers provide a mechanism and method for the eventual translation of the program and its interface to suit local preferences and languages for users worldwide.
WordPress developers have done this, so in theory, WordPress can be used in any language. The second step is the actual localization, the process by which the text on the page and other settings are translated and adapted to another language and culture, using the framework prescribed by the developers of the software. Translating WordPress Qualifications About Locales GlotPress.
I18n for WordPress Developers. I18n for WordPress Developers The Plugin Internationalization documentation is now located in the Plugin Developer Handbook. The Theme Internationalization documentation is now located in the Theme Developer Handbook. What is I18n? Internationalization is the process of developing your plugin so it can easily be translated into other languages. Localization describes the subsequent process of translating an internationalized plugin.Internationalization is often abbreviated as i18n (because there are 18 letters between the i and the n) and localization is abbreviated as l10n (because there are 10 letters between the l and the n.) Why internationalization is important? Because WordPress is used all over the world, it is a good idea to prepare a WordPress plugin so that it can be easily translated into whatever language is needed. Introduction to Gettext WordPress uses the gettext libraries and tools for i18n. Here is how it works in few sentences: Text Domains Strings for Translation Placeholders.
PHP Text Scanner and .po File Generator [ICanLocalize] Translating WordPress into another Language. This guide is another in the Inside WordPress series and attempts to show how to produce a translation for an already-prepared theme, plugin, or WordPress itself. Even if you have little PHP or HTML skills you can still contribute to making WordPress a truly international experience by providing localizations for existing themes and plugins. The guide will be written from a beginners perspective and will not assume any knowledge of PHP or HTML (although some will be helpful). Detailed explanations will be given at every stage and you are invited to provide feedback or pose questions.
If you are a plugin or theme writer then please take a look at Preparing A Theme Or Plugin for Localization, another in the Inside WordPress series that is specifically targeted at the steps involved before a translation can occur. An Overview of localization WordPress uses a standard localization framework called GNU gettext. Text is marked by wrapping it with special PHP functions. Tools Of The Trade. Download. Poedit Pro Downloads Open Source version & source code Up-to-date source code of the Open Source version of Poedit (sans the Pro features included in the above binaries) is available at GitHub. Windows and OS X versions can only be built from a git checkout.
There's also a tarball of the latest release for Linux/Unix builds: poedit-1.6.4b.tar.gz Older versions Older, no longer supported, versions, including a version that runs on OS X 10.6, are available from SourceForge archive. Category:WP-Cron Functions. Automating your plugin with WP-Cron. Theme Code Matters, Too. Hey there, WordPress theme developers. When you’re crafting themes, are you checking the quality of your theme code? The design is important, yes, but so is the code. Within the past year, the WordPress theme review team has been hard at work encouraging best coding practices among WordPress theme developers, with the goal of raising the overall standard of the themes that appear in the WordPress.org theme repository.
Even if you don’t intend to submit your theme to the WordPress.org theme repository, it’s wise to develop your themes as though that was your intention. I hope that by the end of this post, you’ll have a better understanding of the benefits of doing so. The WordPress Theme Review Team and its guidelines Just in case this is the first time you’ve heard of the theme review team, I’ll describe it briefly. Briefly, a description of each of the above: The Theme Check plugin This is a plugin that tests your theme to see if it meets the latest theme review guidelines. Code quality. New Plugin to Style your Plugin on WordPress Admin with Default Styles! - Plugin, WordPress, Here, Github, githubcombueltgeWordPress-Admin-Style, HTML. WordPress is developing fast - this also applies to the design of the backend. So it is important not to use your own styles in the admin area and use tags and classes of WordPress. This is the best way you can simplify your work as a developer and you don't have to test the design with every update.
Unfortunately, there are quite extensive opportunities in the backend to implement the requirements. Several different classes and HTML structures are used. You can find the Plugin in Github and it would be great if you expand it, add new ideas and possibilities to it: - github.com/bueltge/WordPress-Admin-Style. Theme Unit Test. Theme Unit Test Languages: English • 日本語 • Español • (Add your language) (Last Edited: 2014-1-6) This step in Theme testing correlates to a WordPress export (WXR) file that you can import into a WordPress installation to test your Theme. To be clear, this is only one step in testing your Theme.
See Theme testing for a full guide. Setup Test Environment Setup Download test data: (updated 01/06/14 16:36 UTC) Import test data into your WordPress install. WordPress Settings Adjust WordPress settings as follows: Settings -> General: set the Site Title to something fairly long, and set the Tagline to something even longer. Create at least two Custom Menus: Long Menu: all included Pages Short Menu: a menu of 2-3 Pages Template Hierarchy Index Pages Posts display correctly, with no apparent visual problems or errors. Static Front Page 404 Page Search Results Page Blog Posts Index Page Scheduled Post Draft Post Layout Test Readability Test. Wp-admin-style.php at master from bueltge/WordPress-Admin-Style - GitHub. Sticky Posts. Sticky Posts Sticky Posts is a feature introduced with Version 2.7. A check box is included on the Administration > Posts > Add New Screen (In the Publish panel under Visibility.
Click edit to see the checkbox). If checked, the post will be placed at the top of the front page of posts, keeping it there until new posts are published. Please notice that this feature is only available for the built-in post type post and not for custom post types. Function Reference Display Sticky Posts Show Sticky Posts Display just the first sticky post: (Note: At least one post must be designated as a "sticky post" or else the loop will display all posts.)
$sticky = get_option( 'sticky_posts' ); $query = new WP_Query( 'p=' . Display just the first sticky post, if none return the last post published: $args = array( 'posts_per_page' => 1, 'post__in' => get_option( 'sticky_posts' ), 'ignore_sticky_posts' => 1 ); $query = new WP_Query( $args ); Display just the first sticky post, if none return nothing: <?
Related. Definitive Sticky Posts Guide for WordPress 2.7. As the blogosphere is abuzz about all the cool new features in WordPress 2.7, I’ve seen very few (if any) good posts on the new Sticky Posts feature that will allow you to take any story, or stories, you’ve published and place them at the top of your homepage without editing the timestamp. This new feature will allow you to take posts that you’re especially proud of and display them for all the world to see for as long as you want.
But for many theme and plugin developers, and even users who may want to do a little DIY theme hacking, there is very little documentation for getting the feature set up to do the things you want it to. That’s where this guide comes in. Turing a Post into a Sticky Post In the 2.7 Post edit panel, over in the publish module, you’ll notice a little checkbox. Also, it is worth noting that a post can be made “sticky” using the “Quick Edit” panel as well. Styling a Sticky Post <? <? Depending on what type of post it is, it will output different kinds of stuff.
Tutorial: Using the WP_Filesystem. Note: An actual working implementation of the WP_Filesystem can be found in my Pluginception plugin. Lot of talk amongst theme authors recently about writing local files. Writing files from code, whether it be from a theme or from a plugin, is generally bad mojo. However understanding why you shouldn’t is confusing to many, and then understanding why you shouldn’t do-it-yourself and should use the WP_Filesystem is even more confusing.
To further muddy up the waters, many theme authors have expressed confusion at how to use WP_Filesystem in the first place. So, let’s run the gamut in this tutorial. Note that I wrote it quickly, so it may be uneven in parts. Why Not To Do It The most common reasons I see theme authors wanting to write local files falls into three categories: Dynamic CSSConfiguration SavingExport/Import Take the Dynamic CSS case to start with, since it’s the most common one by far. Security is going to be a big issue for the next two items, so I’ll cover it right now. Custom taxonomies in WordPress 2.8. Excerpts and taxonomies for pages in WordPress 2.9.
Wpmu. Plugins.