In the last two months we’ve seen a number of WordPress security updates. April 21 brought us WordPress 4.1.2 which fixed 4 security issues. A wide-spread vulnerability in numerous WordPress plugins was simultaneously announced and was followed by a rash of plug-in updates by vendors including Yoast. A week later WordPress 4.2.1 was released with a patch to a cross-site scripting vulnerability found in the comments feature. Then just a few days ago WordPress 4.2.2 patched a vulnerability in the bundled Genericons font package. The WordPress naysayers have been saying nay for weeks now. Is their negativity justified?
The WordProcalypse ended not with a bang, but with a “meh.” WordPress updates itself automatically now. And if you’re in the practice of only installing reputable plug-ins and themes, updating your plug-ins is pretty painless.
Consider this: all of the vulnerabilities fixed by these updates were detected either by the core WordPress team or community members who develop extensions. None of them were the results of a zero-day exploit.
I think the recent rash of WordPress Core and plug-in security updates is a Good Thing. It’s proof-in-the-pudding that the WordPress community has matured. It’s a sign that everyone involved in WordPress’s success from parent company Automaticc to lone plug-in authors are taking it seriously.
/wp-content/uploads/2019/09/reich-web-consulting-logo-o.svg00Brian Reich/wp-content/uploads/2019/09/reich-web-consulting-logo-o.svgBrian Reich2015-06-08 20:56:242015-10-05 11:30:36On the Recent WordPress Security Updates
I get it: sometimes project scope, cost, and time limitations get in the way of doing the right thing. That’s why professionals who damn-well know better take shortcuts like using inline styles. These tactics rarely save time in the long-term. This article explains why and suggests some long-term solutions to the problem of inline styles.
What Is an Inline Style?
Inline styles are CSS styling rules that are embedded directly into your HTML markup in the form of either a <style> tag or the attribute style="".the tag They’re the opposite of external style sheets, which are CSS styling rules defined in an external file that gets linked into your HTML the tag<link/>.
Both types of inline styles suck, and I’m about to tell you why.
Why Do Inline Styles Suck?
I’m of the opinion that we should avoid <style> and the style="" attribute except in the most basic situations. Why would I make such bold assertion? Because of experience, that’s why! There are many reasons that inline styles suck.
Inline Styles Defeat the Purpose of CSS: Separation of Concerns
If you’ve been in the web design business long enough, you’ll remember how hard our forefathers like Jeff Zeldman worked to pave the way for the semantic web (a pipe dream, for better or worse).
To sum it up, folks like Zeldman fought for all browsers to support some very basic features. They wanted support for XHTML: a markup language that defines the structure and meaning of the words on the page, and not so much their style. They wanted support for CSS: a language that describes how those words should look on screen, in print, and on various other devices. Their reasons?
Web Standards. Sites were bloated with browser-specific code because no browser supported the “standards” in a standard way. An <h1> on one site may be a different size and weight from one browser to the next.
Accessibility. Talented designers realized that out of necessity they were using semantic tags like <table> and <h1> – <h6> to affect style and positioning, and it was making the web less accessible. Nonstandard devices such as screen readers were choking on the spaghetti code needed to make sites render on standard web browsers and devices.
Page Weight. Marrying content to presentation meant that every page, no matter how similar it was to every other page on a site, had to download a fresh copy of all its styling. Divorcing presentation from markup makes the size of a page much smaller. A single style sheet can define the design for an entire website, and no matter how many pages a user views or how often the content changes, that style sheet need only be downloaded once.
Inline styles defeat many of the goals of semantic markup. Inline styles add to page weight and must download each time the page loads, even when the styling hasn’t changed. The style="" attribute is especially nasty: it remarries presentation and content, making it impossible for devices to style differently based on context.
And while most designers don’t give a damn about how an inline style might add a few bytes of page weight or how assistive technology might interpret their page, they probably do care about mobile.
I recently ran into a situation where dozen of pages created inside a CMS were given two-column layouts by using inline style attributes to define floats and static widths. This was fine before the mobile web was a thing and every browser could handle a 960 Grid System layout. But by defining positioning inline on dozens of pages, the developer effectively made the job of making this site mobile friendly far more difficult. The Fiddle below shows what happens to these column definitions when they appear in a 960gs page versus mobile:
Inline Styles Defeat Style Sheet Optimization
There are several methods for loading CSS more efficiently, and none of them apply to inline styles:
Combining External Resources. The first is to combine any external CSS resources into a single file. Even though the resulting file is just as big as the sum of it’s parts, it requires only a single browser request to fetch it. On a site that loads numerous style sheets (for example, a WordPress site with a lot of plug-ins installed), the savings can be substantial. Unfortunately internal styles are rarely, if ever, optimized by these tools.
Minifying CSS. If you’re not minifying your CSS, you probably should be. Minification is the process of running your CSS scripts through a tool that removes any unnecessary content such as comments, white space, and redundant rules. Again most CMS packages can minify your CSS for you, but only if they’re in external style sheets.
Caching. Caching rules can be applied differently to different types of content. Once design on a website is complete the style sheets will change very infrequently, so the environment can be configured to provide the user with a fresh copy of a site’s external CSS files very infrequently, limiting the time it takes the user to download the new file and conserving costly bandwidth for both the user and your website. Unfortunately if your style rules are part of the page content, your styles will be cached the same way as the rest of the page.
Inline Styles Make Finding the Source of a Style Difficult
Consider a pretty simple example. You’ve got a website managed by a content management system and you want to change the styling on a particular page. (Let’s say it’s WordPress for this example, but it really doesn’t matter.) First you need to find out where the current styling originates so you can change it. Being familiar with the CMS you know that styles could be set by:
The theme’s external style sheet style.css.
An external style sheet loaded by a plug-in.
An inline style in a <style>...</style> block hard-coded into one of the theme’s templates such as header.php, page.php, footer.php, etc. The possibilities are as numerous as the number of templates in the theme.
An inline style in a <style>...</style> block hard-coded into a plug-in. The possibilities are as numerous as the number of plug-ins you have installed.
An inline style in a <style>...</style> block hard-coded into the content of a page in the CMS. You’d have to login and update the page content to change the styling.
An inline style in a style attribute hard-coded into one of the theme’s templates. Again, we have numerous possibilities for where it could be located.
An inline style in a style attribute hard-coded into a plug-in.
An inline style in a style attribute hard-coded into the content of a page in the CMS.
A style dynamically assigned to an element using JavaScript.
It’s pretty obvious that locating a style’s origin gets pretty complicated when you stop stashing styling rules in a common location like style.css. Tools like Firebug and Chrome’s Developer Tools can help you determine the source of a given style. They’ll even tell you the exact line number in an external stylesheet where a style is defined, or tell you where in the HTML markup an inline style has been defined.
The key words in that statement are “in the HTML markup.” Remember 20 seconds ago when I listed all the server-side code that could be generating inline markup? Tools like Firebug can only tell you where a style is defined in the HTML markup the browser receives. They can’t tell you which server-side code generated the markup. Relying on inline markup can leads to entire hours lost searching server-side code and database content just to figure out why a certain element is bold, the wrong color, or badly positioned.
Inline Styles Solve Today’s Problem & Creates Tomorrow’s
Inline styles contained in a <style>...</style> block only affect elements on the page in which they live. Styles in an style="" attribute only affect the HTML element on which they’ve been defined. So by their very nature inline styles create scenarios where copy/paste feels like the only solution, and by extension they introduce inconsistencies into your web design. Consider the code below. In the HTML markup we have a single <div/> with a class="message" and some inline styles to make it look like an error message.
We’re so thrilled with our new error message styling that we decide to use it on a few other pages! But since our styles are inline and we don’t want to waste time editing what already works and creating an external style sheet, we copy & paste what we already have.
Months later we realize that our background color isn’t exactly easy on the eyes and want to change it. First of all months have past and we may not even remember writing this code, and must track down where the styles are defined. Second, we realize because of our up-front laziness we now have to change it in several different places, and if we miss even one, our message styling won’t be consistent throughout the site. At this point we realize that it would have been far easier and far more consistent to just externalize our style in the first place. In the example below I’ve moved the styles to an external style sheet, where changes only need to be made once:
Why Do Developers Use Inline Styles?
All the points I’ve made in this article are pretty well-known. So why do seasoned developers that ought to know better still keep using inline styles?
Excuse 1: Project Constraints
If you’ve been given a common task like changing the layout or the fonts on a single item or a single page, an inline style might feel like the best solution to that specific problem. The project scope might be “made this heading bolder” or “switch the Products Page two a two-column layout”, not “create a reusable style for page headers” or “create a responsive two-column layout for page Y.” Not only are you not getting paid to think about how your solution might effect the site in the future, your work culture might completely disincentivize doing things the right way by rewarding quick, billable solutions, no matter how hacky or void of forethought they may be.
Explain to your boss why you should take the time to solve the problem the right way, and do it. Unless you’re working with an inferior CMS that gets in the way of getting your work done, it shouldn’t take much longer than adding the CSS inline.
Excuse 2: Technical Constraints
Some content management systems don’t provide a way to target a specific piece of content with CSS other than including the CSS in the content itself. This was true in old versions of WordPress, and the problem still exists in themes that don’t follow the practice of calling body_class() in their header templates.
Whether you’re working on a framework of your own design or an open source CMS, your workflow should provide a way to target specific pieces of content, and a common location for stashing CSS. If it doesn’t, your workflow should probably be improved. Here are two examples, one off-the-shelf and one custom:
In WordPress styling is stashed in the current template’s style.css file. Plug-ins should (but don’t always) import styles from their own style sheets. Each page you create provides a body class that allows you to target specific content from within the external style sheets, eliminating the need for in-line CSS.
In my employer’s in-house CMS, we stash CSS in /styles/custom.css. Each piece of content stored in the CMS has a unique id that is used to set a body class, which allows you to target specific content from custom.css, eliminating the need for in-line CSS.
Summary
Last Friday my entire day was consumed by fixing problems caused by other people’s erratic use of CSS. A perfectly good mobile template was blasted to bits by inline styles coded into page content saved in their live CMS. While I’m sure there are some situations where an inline style might be the best solution, I have yet to run into any of them. Please style responsibly.
Well I finally installed Windows 8 because, well… somebody has to, right?
Truth be told I was hesitant. I’m normally not one to buck changes but when I saw what Microsoft did to the UI I felt concerned about what was going to happen to my work flow. To put it another way: WHERE THE HELL IS MY START BUTTON, MR. BALLMER?
Unfortunately we’ve gotten our first handful of Windows 8 devices at work and, since I’m responsible for desktop support, I pretty much have to learn it.
Fortunately (or unfortunately) for you, I’m taking all of you along for the ride. Watch me screw up so you don’t have to!
The first and arguably most important step in creating a WordPress Plugin is choosing a name for it. If you plan to share your plug-in with others it should obviously be catchy, but more importantly it should also be unique for two very good reasons explained below.
Make Your Plugin Stand Out
WordPress has a vast number of free and commercial plugins available. If you choose to share your plug-in with others you’ll want your plug-in to stand out from the rest. Before you decide on a name for your plug-in, use Google and the WordPress Plugin Directory to do some research. Rather than call our recipe plug-in that we’ll be creating simply Recipes, we’re going to call it Delicious Recipes, by Reich Web Consulting.
Namespacing
Regardless of whether or not you choose to share your plugin with others, when you begin coding you’ll have to make decisions about naming things like functions, classes, constants, and other identifiers. Identifiers must be unique not just within your plugin but to PHP, WordPress, your active theme, and any other active plug-ins. Defining two identifiers with the same name will result in a namespace collision: an error condition in which two or more identifiers have the same name. Lets say we’ve written the following PHP code:
// Intentially cause a namespace collision: functionprintf($args){// Function definition}
// Intentially cause a namespace collision:
function printf( $args ) {
// Function definition
}
Because the printf() function already exists in PHP, the following error is generated:
Using the PHP and WordPress documentation you can safely avoid namespace collisions with PHP and WordPress, but how do you avoid colliding with the thousands of other plugins and themes that you and others might install alongside of your own? The answer is to namespace your plugin code.
How do you namespace your plug-ins? It’s as simple as choosing a prefix that’s presumably unique to your plug-in and appending it to all global identifiers. The name of my company is Reich Web Consulting and the plug-in we will be developing is for managing recipes, so I’m going to choose RC_Recipes as my namespace:
<!--?php /* * Define a namespaced class. */class RC_Recipe_Plugin {// Class code } /* * Define a namespaced function. */ function rc_recipe_plugin_function( $args ) { // function code } /* * Define a namespaced constant. */ define( 'RC_RECIPE_CONST', 0 ); ?-->
<!--?php /* * Define a namespaced class. */ class RC_Recipe_Plugin { // Class code } /* * Define a namespaced function. */ function rc_recipe_plugin_function( $args ) { // function code } /* * Define a namespaced constant. */ define( 'RC_RECIPE_CONST', 0 ); ?-->
If you’re experienced with PHP you might be wondering why we don’t solve the problem of namespacing by using PHP’s built-in namespace feature. The reason it’s not used is because, at of the time this tutorial was written, WordPress requires version 5.2.4 of PHP, which does not support namespaces. While you could still write your plug-in using PHP namespaces you would be seriously limiting the number of people that could use it by requiring a version of PHP newer than that which WordPress itself requires.
Summary
Before you go all gung-ho slinging code it pays to takes a few minutes to consider the design and marketing implications of naming your plugin. Choose something unique but catchy, and use your plug-in name to create a unique namespace for your code. In the next part of this tutorial we’ll be creating the directory and file structure for out plugin. Catch you then!
https://www.reich-consulting.net/wp-content/uploads/2012/11/wordpress-logo-stacked-rgb.png310499Brian Reich/wp-content/uploads/2019/09/reich-web-consulting-logo-o.svgBrian Reich2012-11-06 14:36:552012-11-06 14:36:55Creating a WordPress Plugin, Part 1: Naming Your Plug-in
In my last article I talked about WordPress Posts, one of the two primary content types in WordPress. In this article I’d like to talk about WordPress pages.
What’s a WordPress Page?
WordPress Pages are your blog’s primary content. That’s not to say that they’re more important than your blog posts, but rather that they support your posts and are available wherever a user might find themselves on your site. To quote WordPress.com,
Pages live outside of the normal blog chronology, and are often used to present timeless information about yourself or your site — information that is always applicable.
Another way of looking at WordPress pages is that they are the items that appear on your primary navigation.
If you want to use WordPress to build a static website (just a few pages that rarely change, as opposed to a blog with dynamic, changing content) you can do this with WordPress pages. Simply create your pages and configure WordPress to use one of them as the front page.
What Content Should I Put in my WordPress Pages?
Pages can contain just about anything you care to put on them, but there are some classic examples.
A page might offer background on you or your company (“About Me”). It might display an email form and phone and mailing address information (“Contact Us”). It could display an outline of your site that helps your visitors find the content they’re interested in on your site (“Site map”). If you’re WordPress site provides e-commerce you’ll probably have a “Shop” page, or if you’re site focuses on a retail product you might have a “Store Locator.”
Creating and Editing WordPress Pages
If you want to create a new page, log into your WordPress Dashboard and click Add New under the Pages heading on the Dashboard menu. If you want to edit an existing page just find the page by clicking on the All Pages link under the Pages heading.
The Page editor looks like the Post editor with a few exceptions. Let’s talk about each item in some detail below.
The Page Title
The page title is the name of the page. It will appear as the link text in your navigation, the title that appears at the top of the user’s web browser, and the heading that appears above the page content in most WordPress themes. Give some thought to your page title, as you probably won’t want to change it often. If you’re editing a page that appears on most websites such as About Us or Contact Us, don’t get too cute. Visitors get accustomed to finding information under certain headings, and using different language may make finding it confusing.
If you’re concerned about search engine optimization, use a plug-in like WordPress SEO by Yoast to help you choose keywords and include them in your title.
The Page URL
The page URL appears just below the page title. The bulk of the URL is automatically generated using your site’s permalink structure, but you can edit the part of the URL specific to the page, called the page slug. By default your page’s slug is automatically generated when you create the title.
The Page Content
This is where you will actually design your page and add text, images, videos, and just about anything else to its body. The editor functions in Visual and HTML mode. Visual Mode provides the following features:
Upload and insert images and other media.
Font styles such as bold, italic, and strike-through.
Lists (orders as well as unordered).
Text alignment (left, right, centered)
Creating hyperlinks both within and outside of your WordPress site.
Spell-check
Page breaks
HTML hierarchies and formats including headers (h1 through h6 tags), block quotes, and addresses. Utilize these features as much as possible to break your article into logical components.
HTML mode is for folks who know HTML and want more control over their content. Just remember that you can switch modes at any time, but if you author a page in HTML mode and switch to graphical mode to make some edits, be ready for the editor to break your carefully crafted HTML markup!
Publish Options
The Publish box, or meta-box in WordPress terms, lets you control who, if anyone, can view the page. Clicking the Publish button saves your page and any settings that you’ve changed. If your page is already published, the Publish button will say Update instead. Before you publish your page you will also have the Save Draft option which allows you to save your post without making it publicly available on your site. For example I’ve saved this page as a draft 5 times already because I needed to stop writing and return to finish it later.
The Status option provides three options:
Draft – Your page is in the editing process and won’t be displayed on your public site.
Pending Review – Similar to draft mode. A post pending review requires an administrator to check and publish it.
Published – Your page is complete and is visible on your public site.
Scheduled – Similar to Published, but your post is not visible until a specific date.
The Page Visibility option provides several options as well:
Public – Public visibility (the default) means that anyone browsing your WordPress site can view the page.
Password Protected – WordPress prompts visitors for a password to view the page.
Private – Only authenticated users (like admin or other users you have creates within WordPress) will be able to view the page.
The Publish option allows you to choose to publish the page immediately or at a specific date and time. This is useful if you would like to author a page ahead of time that isn’t visible until a specific date, such as a page about a fundraiser that begins on a specific date.
Page Attributes
By default the Page Attributes meta-box allows you to set the parent page, template, and order for the page that you’re editing.
The Parent Page option allows you to organize your pages into a hierarchy. If you begin to accumulate a lot of pages, you’ll soon notice that they break your top-level navigation, or at the very least make it look ugly! At this point you’ll want to consider grouping your pages into a hierarchy, in which similar pages are grouped together.
For the sake of argument let’s say your site has the following pages: About Us, Contact Us, Our Staff, Shop, Directions, and Sitemap. Making About Us the parent page for Contact Us, Our Staff, and Directions makes sense because these pages provide additional information about you or your company. Sitemap and Shop do not. In addition, they’re important enough that you would want them to be top-level navigation items anyway.
The Template option allows you to change the layout for a particular page, however the template options available are completely dependant on your theme. Many themes provide one, two, and three-column templates or templates designed for a specific function such as highlighting an image or a video.
The Order option allows you to customize where in your navigation menus this page will appear. A value of 0 is the default. A lower value will place a page closer to the beginning of your menu, whereas a higher value will place the page closer to the end. A tie between pages with the same order is broken by the alphabetical order of their titles.
Featureds Image
The Featured Image option is theme-specific. That is, support for this option must be built into the active WordPress theme in order for this option to be visible on the Page editor. This option allows you to upload an image to WordPress and assign it to the post. How it displays on your site is completely up to the theme.
https://www.reich-consulting.net/wp-content/uploads/2012/07/Page-Editor.jpg9231280Brian Reich/wp-content/uploads/2019/09/reich-web-consulting-logo-o.svgBrian Reich2012-07-15 10:36:582017-12-29 13:41:51WordPress Pages and the WordPress Page Editor
