• the user experience is marred by having to open a mail client, paste the address and type a message, or clicking on the link, having the mail client appear, and typing a message.
• an email address embedded into a page’s markup becomes a target for email harvesters, which trawl the web looking for unprotected email addresses that they can then spam.

There are technical solutions to avoid the email harvesters, but this still leaves the user experience issue on the table. Fortunately, there is another option which addresses both issues: contact forms.

A contact form makes use of HTML form elements to present some form fields for the user to fill out, and a button to submit the message. There’s usually some validation, client side and/or server-side, to ensure the form is filled out correctly, and some styling to make the form appealing to the eye. No need to involve an email client, and no vulnerable email addresses for harvesters to catch.

This can be prepared manually by a developer, but a savvy WordPress webmaster can use a plugin to handle the details. This is where Contact Form 7 comes in.

The bulk of this article will be a tour through Contact Form 7′s creation, editing, and modification processes. The tour will be followed by a section covering some slightly advanced steps that can be taken to further enhance the form. But first, an introduction.

Introducing Contact Form 7

Contact Form 7 (CF7) is a popular plugin which simplifies contact form creation to a matter of clicks in the WordPress backend, and pasting a shortcode into the desired location for the form to appear.

In short, CF7 has the following notable features:

• allows custom styling
• can check submissions for spam
• supports validation for:
  • required elements
  • input formats
  • content length limits
• supports CAPTCHA
• AJAX-based submissions
• extensibility via hooks
• HTML5 form elements and attributes

At the time of writing, the current version is 3.4, published on April 8, 2013. The plugin has almost 10.4 million downloads. This is a major update, several months after the previous major revision. A notable improvement is support for HTML5 form elements and attributes.

The next section is a tour of CF7‘s features, as well as the creation of a basic contact form.

Tour of Contact Form 7

This plugin is available in the WordPress plugin repository, and can be brought into play by the standard download-install-activate dance. Once activated, the plugin shows an entry in the WordPress admin menu:

Hitting that link sends the user to the CF7 administration page:

The plugin automatically creates a basic contact form. Note that the Add New button at the top of the page allows creation of multiple contact forms. The default form can be edited by clicking the form title; doing so brings up the form editor. It’s a rather long page at the outset, though the individual sections can be collapsed, expanded, and moved in a manner similar to the WordPress dashboard. Each section will be examined in succession, starting at the top.

Title

The topmost section contains the form’s title. This is more for management through the backend than anything else. The title can be clicked on to modify it; click on the nearby Save button within the box after doing so. Note the boxed-in text below the form title: this is the shortcode that can be pasted into one of the site’s content sections to show the form.

Form

The textarea on the left takes a combination of markup and shortcodes. This setup allows full customization of the markup that goes into a form. The shortcodes are local to the CF7 plugin – they are placed where corresponding HTML elements are to appear when the form is rendered on a page. The asterisk (*) adjacent to the element type indicates that the field is required; if the asterisk is omitted, the field is considered optional.

The contents of the default form are:

<p>Your Name (required)<br />[text* your-name]</p>

<p>Your Email (required)<br />[email* your-email]</p>

<p>Subject<br />[text your-subject]</p>

<p>Your Message<br />[textarea your-message]</p>

<p>[submit "Send"]</p>

The shortcode syntax is well-detailed on the plugin’s website. Take a look for the full details, but in short, shortcodes can also specify content length, id, and class attributes.

Also observe the dropdown box at right; it contains items that, when clicked, will cause appropriate shortcodes to appear in the textarea at left. There’s a good number to choose from, covering most typical contact form elements. The choices include:

• text fields, including email, URL, telephone, date
• textareas
• select lists
• check boxes
• radio buttons
• file upload
• captcha
• quiz
• acceptance checkbox
• submit button

A notable addition here is the support for HTML5 form elements, a worthwhile component of the ever-evolving HTML specification.

The form is currently pretty straightforward and typical for a contact form. There is more that can be done, but the default will do for now.

Mail

The next section down is for Mail settings. The data entered here represent various details around the sending of an email:

• to
• from
• subject
• additional headers
• file attachments
• content type

Of interest is the ability to specify additional headers for email messages. One such possibility is CC-ing the message to another recipient; BCC is also an option. The values for these can be hard-coded here, or they can retrieve values from fields listed in the previous section. This field is documented briefly on the plugin website.

It is also possible to specify the body of the email, including the submitter’s message, in the nearby textarea:

From: [your-name] <[your-email]>
Subject: [your-subject]

Message Body:
[your-message]

--
This mail is sent via contact form on [sitename] [site-address]

The [site-name] and [site-address] items above are placeholders written for this example; the plugin automatically uses the site name and address from the WordPress settings on this line.

There are a number of shortcodes available here, based on which fields are added in the form section shown earlier. With the default form, the following shortcodes are available:

• [your-name] – submitter’s name
• [your-email] – submitter’s email address
• [your-subject] – message’s subject
• [your-message] – message content

The shortcode names here match the names assigned to the form elements previously.

One last thing to note: there are additional shortcodes that can be referenced within this section. These include the URL of the contact form, the submitter’s IP address, and the date and time of submission, among other things.

Mail (2)

Continuing on, the Mail (2) section provides the ability to send a copy of the email to a separate recipient. Checking the Use mail (2) checkbox will reveal form fields similar to the Mail section already covered. Same fields, same shortcodes. This could be useful for sending a copy of the message to the submitter’s email. The author notes that this second message is only sent if the initial one succeeds.

Messages

Part of a good form experience is providing feedback to the user. Such feedback can be varied, but often includes a notice of successful submission, a notice of errors in the entered data, or notice of a failed challenge response. CF7 supports the following message types:

• success
• failure
• validation errors
• spam submission
• must accept terms
• required field
• invalid CAPTCHA response
• invalid date format
• date too early
• date too late
• file upload failure
• file type invalid
• file too large
• file upload fails – PHP error
• number format invalid
• number smaller than minimum
• number larger than maximum
• incorrect quiz response
• email address is invalid
• URL is invalid
• telephone number is invalid

That’s 21 different notice types. Some of them are related, such as those pertaining to file uploads, but still, this provides for a lot of flexibility. Default text is provided for each notice type; these defaults can be kept as they are, or can be individually edited. Interestingly, these fields support the use of basic HTML, so it is possible to add text formatting, links, and even images to the generated notice.

Additional Settings

It’s not obvious what this field can be used for. Supposedly it’s intended as a catch-all for other settings that do not fit in any of the previous section. The plugin author has provided a usage example: tracking contact form submissions with Google Analytics.

Short any similar needs, this field can likely be left blank.

Basic Form Demo

Having completed the basic tour, the form is ready to be used. This is simple: copy the form shortcode listed at the top of the form page, just below the title, paste it in any page or post, and save. Viewing said page or post should make the form appear. Here’s what the default form looks like on the Twenty Twelve theme, with validation errors visible:

It’s not overly pretty, but is functional. For allowing site visitors to contact the site owner or administrator, this form is as simple as it gets. There’s more that can be done, however. Additional topics are addressed in the next section.

Advanced Form Management

Labels

An issue with the default form, and the shortcodes, is that they don’t include label elements corresponding to the individual input elements. Such labels are useful for accessibility and usability, since they provide cues to the user that a label is associated with an input element, and the label can be clicked to set the focus on the matching element – especially useful for otherwise small targets such as checkboxes.

There are two ways to make this association: wrap the label around the input, which implicitly creates the association, or use the label’s for attribute to specify which input to match; the value of the label’s for attribute must match the id attribute of the matching input element. The following implementation will use the latter technique, though the former could work just as well.

According to the syntax reference, adding an id attribute to an input element is done by adding the same to an element shortcode. The form markup can be revised as:

<p><label for="your-name">Name</label><br />[text* your-name id:your-name]</p>

<p><label for="your-email">Email</label><br />[email* your-email id:your-email]</p>

<p><label for="your-subject">Subject</label><br />[text* your-subject id:your-subject]</p>

<p><label for="your-message">Message</label><br />[textarea* your-message id:your-message]</p>

<p>[submit "Send"]</p>

This implementation has added the label elements, and removed the (required) bits since they were redundant, with every field now being required. The next screenshot shows the revised form, with all the validation errors visible:

The labels can be clicked to set the focus on their matching form fields; the form also requires that all fields be filled in before submission.

The validation errors don’t stand out too much, and could use some enhancement. Also, the labels aren’t obviously labels – they look like raw text above each field. There should be a cue to the user that labels are clickable to set focus on the matching fields. These are styling issues, which will be examined in a little more detail at another time.

Controlling Scripts and Stylesheets

By default, CF7 automatically loads it’s own custom script and stylesheet files into the page header, for each page. This is needless for pages that do not have a contact form. According to the plugin author, there isn’t an easy way to detect whether a contact form is present on a page when that page starts loading. The workaround is to disable automatic script/style loading, and to only load these files on pages where it is known that they are needed. Such as, say, a contact page…

The CF7 website provides information on handling this scenario. The long and short of it is adding the following lines to the site’s wp-config.php file:

define('WPCF7_LOAD_JS', false);
define('WPCF7_LOAD_CSS', false);

These values default to true; setting them to false prevents autoloading of the script and style files. The next step is to add the following to a template for the contact page:

<?php
if ( function_exists( 'wpcf7_enqueue_scripts' ) ) {
    wpcf7_enqueue_scripts();
    wpcf7_enqueue_styles();
}
?>

This will cause the files to be specifically requested for the one page. This assumes that there is only one page hosting a contact form; more involved solutions may be needed where contact forms may be used in multiple places on a website, but this technique shows how it can be done.

Avoiding Spam

As much as a contact form avoids the problem of bots harvesting email addresses, the form itself can be subject to automated spam submissions. There’s also nothing preventing humans from manually submitting spam. There are two techniques that can be applied to address both problems, discussed next.

Honeypots

To address the first issue, it’s worthwhile to make use of a honeypot on the form. A honeypot attracts spam bots, which then submit spam in the form, and the submission can be summarily dropped. This works because bots are dumb, and they try to fill in every field in a form before submitting it. The actual honeypot is a hidden field, which a human would not see or fill in, but for which a bot will happily submit a value. Thus, when the submission system detects that the honeypot field has been given a value, the submission is considered spam and can be dropped.

This technique can be implemented by a plugin to supplement the capabilities of Contact Form 7. The plugin is Contact Form 7 Honeypot, and is freely available on the WordPress plugin repository. No configuration is needed after activation. Just return to the form editing view and activate the Generate Tag dropdown – there should be a new Honeypot option, as shown below.

Selecting the Honeypot option brings up a settings view, which just asks for a name to assign to the field. The recommendation is to make it a random string so it can’t be guessed by bots. Then just copy the provided shortcode and paste it into the form content area.

After the honeypot addition, the form content resembles the following:

<p><label for="your-name">Name</label><br />[text* your-name id:your-name]</p>

<p><label for="your-email">Email</label><br />[email* your-email id:your-email]</p>

<p><label for="your-subject">Subject</label><br />[text* your-subject id:your-subject]</p>

<p><label for="your-message">Message</label><br />[textarea* your-message id:your-message]</p>

[honeypot honeypot-268]

<p>[submit "Send"]</p>

Refreshing the page or post the form is located on, then examining the source, reveals an added section of the form:

<p>
  <span class="wpcf7-form-control-wrap hiddenhoneypot-268" style="display:none;">
    <label for="email-wpcf7-hp"><small>Leave this field empty.</small></label>
    <input class="wpcf7-text" type="text" name="email-wpcf7-hp" id="email-wpcf7-hp" value="" size="40" tabindex="3">
  </span>
</p>

Most humans won’t see the field, as it is hidden from view. Bots will attempt to fill in the field and include it in the form submission. Because the system knows that field should not have a value, the submission can be discarded, and the page will return a submission failure notice.

Another common option for defeating spam bots is the use of CAPTCHAs. While this route may be effective against bots, it also introduces usability issues for genuine users. The honeypot solution is invisible to humans, and is targeted specifically at bots.

Filtering Submissions

While the honeypot solution may effectively deter bots making automated submissions, it does nothing to prevent humans from manually submitting spam. Fortunately, there is a countermeasure for this built into CF7.

WordPress has for quite some time worked closely with the Akismet service to check comment submissions for spam. This functionality is not specific to checking comments, and it can be leveraged to check contact form submissions as well.

This functionality is documented on the CF7 site; an excerpt follows:

• akismet:author
  Add this option to the field that accepts the name of the sender.
  Example: [text* your-name akismet:author]
  • akismet:author_email
    Add this option to the field that accepts the email address of the sender.
    Example: [email* your-email akismet:author_email]
  • akismet:author_url
    Add this option to the field that accepts the URL of the sender.
    Example: [text your-url akismet:author_url]

If WordPress is already configured to use Akismet (and why wouldn’t it be?!), then there’s just a small change to make to the form content. The akismet:... snippets need to be grafted into the existing element shortcodes. Continuing with the running example, the updated form content looks like this:

<p><label for="your-name">Name</label><br />[text* your-name akismet:author id:your-name]</p>

<p><label for="your-email">Email</label><br />[email* your-email akismet:author_email id:your-email]</p>

<p><label for="your-subject">Subject</label><br />[text* your-subject id:your-subject]</p>

<p><label for="your-message">Message</label><br />[textarea* your-message id:your-message]</p>

[honeypot honeypot-268]

<p>[submit "Send"]</p>

There are only options for author name, email, and URL, but only one of them needs to be implemented to cause the whole submission to go through the Akismet filtering process; it is recommended to use all available options where appropriate to maximize accuracy.

The analysis is done on submission; if the submission passes Akismet, the email will be sent to the intended recipient. If the submission does not pass, it will not be emailed, and a submission failure message will appear.

Things to Consider

CF7 provides a number of hooks and filters, making this simple form system quite extensible. There are in fact other plugins available to expand CF7‘s capabilities. This is part of what makes the WordPress ecosystem so attractive.

The plugin’s default styling is spartan, and may not fit with existing themes. This is briefly mentioned earlier, but it is possible to write custom styles. More on this later!

CF7 is pretty flexible; with the elements it supports and the automated processing it can do, along with further extensibility, much more can be done than just contact forms. Ideas that come to mind include project quote forms, polls or surveys, and registration forms. It’s even possible to save the form data rather than emailing it – see the Flamingo plugin, also by the creator of CF7. There is a similar plugin available to save submissions to the database.

Conclusion

Contact Form 7 is widely used, intuitive, and extensible, not to mention current with the times. For the majority of contact forms, which as a whole tend to be straightforward, there probably couldn’t be a simpler way to create as many contact forms as are needed. They can be similar or wildly different, as each can be managed separately. The built-in shortcodes and validation messages are diverse and will cover most typical scenarios.

For now, CF7 looks like the go-to option for any manner of contact, or similar, forms.

Additional Reading

Linked below are some additional resources on using CF7. Enjoy!

• Mini Guide to Contact Form 7
• Contact Form 7 Docs
• Contact Form 7 FAQs

The post Extend WordPress – Contact Forms with Contact Form 7 appeared first on GrantPalin.com.

The post Capsule, The Developer’s Code Journal appeared first on GrantPalin.com.

The post WP Test – The Best Tests For WordPress appeared first on GrantPalin.com.

Author: Tim Steinbach
Publisher: Leanpub
Published: 2012
Pages: 214

Introduction

I got my first experience with using Markdown close to a year ago, and wrote about what I had learned so far a few months ago. While Markdown isn’t a complex topic, I still wanted to have a tutorial to go through, since the official documentation is more of a reference. After some searching, I found Markdown by Example.

The Markdown Breakdown

The book is broken down into three main sections, each with multiple chapters, and an appendix. The first section introduces Markdown, its origin and intent, available editors, installation of supporting software, and references to the book website and code samples. The installation sections covered OS X and Linux – Windows was noticeably absent.

The middle section has two chapters: one for learning the Markdown syntax – it really is simple and straightforward, only one chapter is needed! – and one for a syntax reference. The latter chapter surprised me, coming directly after the instructional chapter; since it is a reference, I thought it might be better located at the back of the book, in the appendix, rather than in the middle, or even as a separate printable PDF.

Markdown is such a simple syntax that it hardly needed any coverage – really, just one chapter to provide the syntax details! However, the meat of the book follows in the third section. This section consists of twelve chapters, covering numerous uses of Markdown for different purposes. These examples include generating HTML output, building websites and blogs, building presentations, writing for WordPress and Wikis, and writing books. That last one, on writing books with Markdown, illustrates how the author prepared this very book and collaborated with Leanpub. It goes to show that for a knowledgeable person who enjoys writing, self-publishing is in reach with publishers like Leanpub and tools such as Markdown!

One other thing of interest is that Markdown is at its heart quite basic and simple – it’s great for text formatting, inserting links, and basic document layout. It does not, however, provide for document elements such as tables, footnotes, and mathematical formulae. There are some extended Markdown implementations out there which to some extent provide functionality beyond the core syntax; the book covers two in particular, namely, GitHub-flavoured Markdown and MultiMarkdown. I’m aware of at least one other, Markdown Extra, so was a little surprised it didn’t receive any coverage like the other two.

The book’s companion website has links to purchasing printed and electronic copies, a book wiki, and a repository of code samples shown and referenced in the book.

Conclusion

Overall, the book is concise and well-written. I have minor issue with the placement of the reference chapter, as well as the incomplete coverage of the Markdown supersets. Combined with the provided code samples, there’s much here to get a Markdown novice underway!

The bottom line: Markdown by Example is a worthwhile and inexpensive read for anyone wanting a gentle introduction to the Markdown format, as well as its possible applications. I recommend it for any Markdown beginner.

The post Review: Markdown by Example appeared first on GrantPalin.com.

• markup
• scripts
• styles
• images
• server configuration
• testing tools

Optimization can seem like a dry subject, but this resource really simplifies the subject, pointing out the simple ways to make gains on page size and speed. Low-hanging fruit perhaps, but even those can add up!

The post How to lose weight (in the browser) appeared first on GrantPalin.com.

This is a welcome initiative because, as powerful as search engines are today, finding relevant, useful, and quality content can still be a challenge for any subject. WP Daily are taking a step to bridging that gap with their Community Resource Library initiative.

The post The Community Resource Library – Help Us Build It! appeared first on GrantPalin.com.

A previous post on template partials showed how to componentize a theme by breaking out reusable blocks of code into discrete files, and consume them via the get_template_part() function. This has the potential to lead to numerous “extra” files located in the theme root folder beyond the standard theme files. WordPress offers the option to organize template files into subdirectories; this post will continue the example in the previous post and show how to make use of this functionality.

Template Files in Subdirectories

As of version 3.4, released in mid-2012, WordPress quietly gained the ability to scan a theme’s subdirectories for template files; this was initially announced by Andrew Nacin. The scanning is automatic, but to actually consume files within the subdirectories takes just a little work.

As shown previously, basic usage of the get_template_part() function is as follows:

// consume the generalized loop partial
get_template_part('loop');

// consume the author archive-specific loop partial
get_template_part('loop', 'author');

With partials in a subdirectory, the function usage is largely the same. The difference is that the subdirectory name must be prepended to the partial’s general name:

// consume the generalized loop partial
get_template_part('partials/loop');

// consume the author archive-specific loop partial
get_template_part('partials/loop', 'author');

That’s all it takes!

Simple Implementation

The most obvious first step is to create a subdirectory to contain the partials; partials sounds appropriate, so that is what gets used here. Use whichever name seems most appropriate. Then it’s a simple matter to move the current partials – namely, loop.php and loop-author.php – into the subdirectory. The resulting directory and file structure is pictured below.

Partial template files in partials subdirectory

Now that the subdirectory has been created and the partials relocated, there’s some editing to do.

The current theme has a home.php file, which is used for a page set as the posts page in the settings; this file, among other things, has a reference to the loop.php partial, as follows:

get_template_part('loop');

Since loop.php has been moved to the partials subdirectory, this reference will no longer work; there will be no error shown – this is by design – but the file won’t be loaded or executed. The fix is simple: prepend the subdirectory name to the partial’s general name, like this:

get_template_part('partials/loop');

This completes the reference needed for WordPress to do its work. Note that the path is always relative to the theme’s root directory. The above change may need to be made in the following files, depending on which are being used in the theme:

• archive.php
• author.php
• category.php
• date.php
• home.php
• index.php
• page.php
• single.php
• tag.php

Following from the example in the previous post, the author archive gets a special treatment. The author.php, contains, among other things, the following line:

get_template_part('loop', 'author');

Note that the use of the specific name does not change the process used to consume a partial located in a subdirectory; that is, just prepend the subdirectory name to the general partial name:

get_template_part('partials/loop', 'author');

As shown in the previous post, it’s not hard to see how this can be used to establish a generalized output pattern for the loop, and then to create specialized versions of the loop for different contexts, as has been done here for the author archive.

Caveats

This technique only works one directory deep. WordPress does not scan deeper than one level below the theme root. Also, standard theme files (the ones WordPress automatically uses when present) cannot be relocated into a subdirectory. WordPress might see them, but will not use them. In some cases, an error is shown on the page, in other cases nothing is shown at all. These files include:

• 404.php
• archive.php
• attachment.php
• author.php
• category.php
• comments.php
• date.php
• front-page.php
• home.php
• image.php
• index.php
• search.php
• single.php
• page.php
• tag.php

Possible Uses

As has been explained, the loop can be generalized for the common case and specialized for the special cases. All of these fragments can be placed in a single subdirectory to keep the theme root tidy. This can be applied to other types of generalizable content, such as:

• paging
• sidebars
• post formats
• named page templates
• content types, e.g. pages and posts

Conclusion

It’s clear that get_template_part() is a very useful function which can modularize themes at the code level. This is further helped by using the subdirectories functionality to organize the resulting partials at the file level. Keeping the theme root as tidy as possible is a good thing; with this technique, only the default files that WordPress expects to see need to be in the theme root.

Other Reading

• Page templates in subdirectories, new in WordPress 3.4 (Andrew Nacin)
• get_template_part (WordPress Codex)

The post WordPress Theming – Templates and Subdirectories appeared first on GrantPalin.com.

Opera just dropped a bomb on the web developer community: they have announced that future versions of the Opera browser will run on the WebKit rendering engine instead of their own Presto. Specifically, they will make use of the open-source Chromium browser, and include the V8 JavaScript engine.

Opera Spills the Beans

As means of early summary, Opera have written the following:

TL;DR

• This will require no changes to your web development practices: keep coding to standards!
• Opera Extensions that you’ve built aren’t obsolete
• Opera will contribute to the WebKit and Chromium projects
• Our work on web standards to advance the web continues

These points indicate that this is largely an under-the-hood change, with little impact on routine coding. Functionally the browser will remain the same, extensions will continue as they have before. Opera are remaining in the browser game, and will have a hand in advancing the web as well as the WebKit and Chromium projects.

Opera’s rationale for the change is that while they built Presto at a time when the competition was sorely needed versus Internet Explorer and Netscape, it now makes less sense to duplicate efforts made on other modern engines (ie WebKit). It’s a reasonable rationale, but to me Opera having their own engine made them stand out as they could implement web standards at their own pace. This has been borne out in the past as they have often been ahead in certain areas. I even remember when Opera was the first browser to have native tabbed browsing, and Firefox at the time required a plugin!

A (quite) probable cause is the trend developers have been following in building styles specifically for WebKit browsers, making heavy use of the -webkit- prefix. This was brought to the fore last year by the kerfuffle around Opera announcing support for certain WebKit-prefixed CSS properties. Today’s news almost seems like a logical next step.

Up until now, the major rendering engine and browser landscape has been:

• Gecko – Firefox
• Presto – Opera
• Trident – Internet Explorer
• Webkit – Safari, Chrome

Given this change, the landscape becomes:

• Gecko – Firefox
• Trident – Internet Explorer
• Webkit – Safari, Chrome, Opera

From what I can tell, this revelation has both positive and potentially negative ramifications.

It’s also been suggested that by switching to the “popular” engine, Opera may lose credibility in web standards development. I don’t see how – they are still Opera.

Peter-Paul Koch made the following remarks:

As many people remarked, we’re trading in a bit of diversity for an easier job as web developers. Opera-WebKit will likely be more similar to the other WebKit-based browsers, thus leading to less premature hair loss among developers. So far so good.

Still, there’s a dark lining to this silver cloud. [...]

The problem I’m having is “many of which have only been tested in WebKit browsers.” Note carefully what this means: we web developers haven’t been doing our jobs properly. We didn’t bother to test our mobile sites on Opera Mini, even though it’s roughly as large as Safari iOS and Android.

I see this as a personal fail. I evidently haven’t been outspoken enough on the topic. I should have yelled in everybody’s ear until they did the proper thing.

It’s our own fault.

Emphasis mine. The quote is revealing in how web developers have essentially forced this situation.

Jake Archibald, a Google employee, reflects on the announcement and what it may mean for the web. Nice to see the pros and cons presented by someone who works for a competing company. John Resig even likens WebKit to jQuery with regard to its widespread use.

The Positive

Opera can contribute their knowledge and skills to the WebKit project, making it all the better. Hopefully things learned from maintaining Presto – such as Opera’s advances in HTML5 form element support – will make a positive impact.

Christian Heilmann touches on this – he remarks:

[...] I always called Opera the Douglas Crockford of browsers as it was ruthless in its implementation of standards. If something didn’t work in Opera there is a good chance that you did something wrong. Even better – fixing it in Opera in most cases meant looking at how the W3C standard meant things to work and write your code accordingly, which in most cases meant no change in other browsers, but cleaner code overall. Opera was my linting tool.

This reflects the care Opera have taken in their implementation efforts. I suspect this would continue, regardless of the engine they use.

Recognizing that there is a difference between the browser and the rendering engine, this move means there will be one less engine to test for. Besides Internet Explorer, browsers tend to be updated on a regular basis, so I don’t imagine Presto-based installs will remain in wide use for long. Peter-Paul Koch estimates the first WebKit-powered Opera will appear this year, and that it will take a few years for Presto use to drop off entirely.

Generally, in my admittedly limited experience, Opera hasn’t been troublesome in standards support, so not much accommodation has been needed. Switching to WebKit will further level out browser differences. Nonetheless, while the -o- prefix in stylesheets will eventually become redundant, they should be kept around for the immediate future for backward compatibility. There aren’t very many. Ultimately this will slightly reduce some development work.

The Negative

While Opera putting their weight behind WebKit can be a good thing, the resultant withdrawal of Presto will reduce diversity in the rendering engine landscape. It’s not to say that Opera (the browser) will become “yet another WebKit browser”, but that it may be less able to distinguish itself from the competition. In the past, Opera (the company) have been ahead in implementing various parts of web standards, notably HTML5 form elements. With the switch to WebKit, Opera’s pace may be tied to that of the WebKit project, for better or for worse. The flip side (also mentioned above) could be that web development and testing may be eased by greater consistency between browsers.

This leads to a concern that the web browser landscape may be moving toward a WebKit monoculture. Sure, there’s still Internet Explorer and Firefox with their distinct engines, but WebKit is a big player on mobile devices, and growing on desktop/laptop systems. This can be good or bad; it’s to early too tell, but it worries me slightly. Competition is a good thing, and removing a player (Presto, in this case) can adversely affect the landscape, and possibly make the other players (the other engines) complacent. Which is kind of veering towards where the browser market was in the early days of Internet Explorer 6.

Returning to the prefixes issue, given the Opera will be using WebKit I have to wonder how browser-specific CSS can be issued. There will be multiple browsers supporting WebKit, yet each browser may use a different version, and likely support different features (as Safari and Chrome have done, I believe). Could styles still be written to target specific browsers, or does using WebKit simply lump them all together?

Time will be the Judge

It’s much too early to know how this will turn out. Here and now, I’m very mixed. In past years Opera has been a unique browser, with it’s own engine and features, with better standards support in some regards. By switching from Presto to WebKit, there is some perception in the community that Opera will become “yet another WebKit browser”. I don’t necessarily agree with that sentiment. I’ve no doubt the Opera team considered this long and hard prior to the announcement, so they may well believe this is the best step forward.

Additional Reading

I’ve been reading a number of other developers sharing their thoughts on this change. Below I’ve linked to a number of very interesting views.

• I will miss the “Douglas Crockford of browsers” (Christian Heilmann)
• Opera switching to WebKit: thoughts and guesses (Peter-Paul Koch)
• WebKit is the jQuery of Browser Engines (John Resig)
• Presto Change-o (Eric Meyer)
• The WebKit Culture & Web Rendering Engine Diversity (Robert Nyman)
• Devs respond to Opera WebKit switch (.net Magazine)
• Opera and WebKit: a personal perspective (Bruce Lawson)

The post Opera to leave Presto, go to Webkit appeared first on GrantPalin.com.

It used to be that WordPress theme templates were monolithic beasts, with a fair bit of looping and conditional logic to display content in a certain way. I know, I’ve done it too. In past years, this has been helped somewhat with the availability of content-type-specific template files, such as page.php, attachment.php, and so on. This helped to reduce the monolithic aspect of, say, index.php and single.php. However, the result was repeated code across multiple files (almost even a multitude). Repeated and redundant code should make any coder cringe. Well, there is a further step to take with the use of a little function called get_template_part().

Introducing get_template_part()

get_template_part() was introduced in WordPress 3.0, and is a more general form of existing functions used to pull in template code from another file (such as header, footer, and sidebar). Indeed, it is now possible to have common code in one file, and use the function to include template code pertinent to a particular content type. The specific files could be termed partials, or fragments.

The function signature looks like this:

get_template_part({general}, {specific});

The first parameter is required, while the second is optional. If both parameters are used, the function attempts to include a file with the following name:

{general}-{specific}.php

If the {specific} parameter is not given, or if it is given and the resulting combination filename does not exist, the function will try to include the {general}.php file. If the {general}.php file does not exist, no file is included. In any situation where the expected partial file does not exist, the general fallback is tried, and if that does not exist, the function ends without errors.

To reiterate, the function behaviour works as follows, stopping with the first action that succeeds:

1. Include {general}-{specific}.php
2. Include {general}.php
3. Exit without error

Another advantage is that the inclusion is always done relative to the theme’s directory, so there is no need to worry about file paths.

This function seems simple, yet when used appropriately can be used to break down theme templates into reusable modules, reducing redundant code and the need for large logic blocks.

get_template_part() is a generalization, is intended to be used for consuming template partials, and is not suitable where existing specialty functions already exist, such as get_header(), get_footer(), and get_sidebar().

An Example Implementation

A common task in theming is looping through content to present a list of e.g. posts or pages. These are often done in different contexts, including author, tag, category, and date archives as well as the index template. Regardless of context, the main loop is usually done similar to the following:

<?php
if (have_posts()):
    while (have_posts()):
        the_post();
?>
<!-- template markup goes here -->
<?php
    endwhile;
else: // no posts found
?>
<p>No posts found matching your criteria.</p>
<?php
endif; // done checking for posts
?>

It’s not a long block of code, but it would have to be repeated in at least the contexts mentioned above. If the output markup was to be kept the same in these contexts, and a change was introduced in one context, the same change would need to be introduced in the other locations as well. That’s just cringe-inducing.

Suppose that this common loop code could be extracted into a fragment, loop.php. In each of the contexts listed above, the common looping code could be replaced with:

get_template_part('loop');

The code block above, based in loop.php, would be dynamically loaded into the current context, executed, and output the resulting markup. This is all well and good if the generated markup is intended to be the same in each context. But if not, then this is an opportunity for get_template_part() to shine.

If a certain context, say the author archive, requires different markup output compared to the other contexts, a specialized loop fragment can be introduced as loop-author.php. Perhaps the other contexts have a common way of showing posts, with thumbnails and metadata, but the author archive is preferred to just have a list of text links to the author’s posts. That’s where loop-author.php would come in; the overall loop would remain the same, but the markup can be changed. The author archive template file can then use the specialized fragment with the following code:

get_template_part('loop', 'author');

The resulting filename would be loop-author.php, and the matching file will be loaded and executed. The contents of loop-author.php could look like the following:

<?php
if (have_posts()):
?>
<ul>
<?php
    while (have_posts()):
        the_post();
?>
    <li><a href="<?php the_permalink() ?>"><?php the_title() ?></a></li>
<?php
    endwhile;
?>
</ul>
<?php
else: // no posts found
?>
<p>No posts found matching your criteria.</p>
<?php
endif; // done checking for posts
?>

Yes, it’s simplistic, but the point is that the posts listing can be generated differently for the author archive versus the other archive types. The output will resemble the following image:

Output of simple get_template_part() implementation.

Following from this, it would be possible to have different loop outputs for each of these contexts, retaining the generic loop.php for cases where no special customization is needed. Whether that would be needed is another matter, but the point is that the use of this technique allows coders to compartmentalize theme components with minimal extra work.

Conclusion

I didn’t learn about get_template_part() until several months ago, even though it has been in WordPress for some time. Once I understood it, however, I quickly realized the ways it can be used to componentize themes and template files, noticeably reducing repeated code yet allowing for customizing output in different contexts. All without requiring large blocks of logic code to determine what to display. This function can be a workhorse, and should be a part of any theme developer’s toolbox.

Additional Reading

• get_template_part (WordPress Codex)
• Understanding get_template_part (Konstantin Kovshenin)
• Tighter and leaner WordPress templates with get_template_part() (Terry Sutton)

The post WordPress Theming – Partial Templates with get_template_part() appeared first on GrantPalin.com.

The post Web Performance 101: An opinionated guide to the 22 links every developer should read appeared first on GrantPalin.com.