A tutorial that shows you how to use Composer and ThinkShout's new PHP library for MailChimp API v3.0 to easily subscribe users to mailing lists in Drupal custom modules without using the MailChimp contributed module. This is a follow-up to a previous post that used the old API, and also includes some new Drupal 8 specifics. Continue reading…
PAX Australia panel "Why We Won't Just Log Off: Surviving Online Harassment" featured people sharing heart wrenching stories about their own experiences, as well as fascinating input from a surprise guest. ...
The event, centered around a minigame from an unreleased 1995 Penn & Teller game, started this past weekend and will continue for as long as people are willing to donate money to the campaign. ...
A lot of effort goes into engaging your visitors to ‘Sign-up’ or ‘Contact’ you. You send them a warm and fuzzy invitation to complete the form, tell them all the great reasons why they should complete the form… but who likes to complete a form? You can help guarantee a smooth sign-up process and increase the completion rate of your web forms with these five tips.#1 Make it Flow
Before you begin designing that web form, it is always good to create a User Flowchart. Working to establish the form completion process from start to finish, a flowchart will help you:
We find that there's still uncertainty out there around upgrading to Drupal 8. The natural answer in the Drupal community is, "Yes, of course go with Drupal 8!", but in the world of tight deadlines and tighter budgets, the answer isn't so clear. Enter ShouldIUpgradetoDrupal8.com, an interactive tool we built to help the community answer that very question.
At GDC 2017, a senior Sony Santa Monica designer who has heard hundreds of game pitches will describe 30 annoying or counter-productive things you should avoid when pitching your game to a publisher. ...
This is the eighth installment of Palantir.net’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.In this post we will cover...
- A recommended naming convention for URL paths
- Some tips for choosing section names
- Questions to consider when defining rules for redirects and aliases
We want to make your project a success.Let's Chat.
A logical progression from Website organization is defining a naming convention for URL paths. URL paths should follow a consistent naming convention throughout all of your websites. Only under exceptional circumstances should a URL path name deviate from an established naming convention for a Website.
Best practices for URL path naming conventions recommend consistency in how sections, sub-sections, pages, and sub-pages are written. For most websites, I recommend URL paths follow the general naming convention below.
This basic structure gives users an idea of where they are in the site’s hierarchy of pages. This can be especially important considering the volume of traffic that enters the site from web searches that will bypass the homepage and take visitors directly into deeper pages in the site. It’s also a good practice for improving the SEO value of your site’s pages, as it provides more specific context for the content of the page.Section
Under this convention, SECTION is the top-level “directory,” and generally refers to the category under which subsequent content resides. For example, in the URL path http://domain.com/about, “About” is a primary category that often appears in a main menu, and thus receives a top-level URL path.
I generally like SECTION names to be one continuous string of letters without hyphens or underscores (e.g. about, services, people, etc.) because that makes for shorter top-level URL paths, however two word hyphens may also be acceptable if they aren’t too long. Given that top-level SECTION names are usually the label-names of your main navigation, it’s additionally wise to keep them clear, simple and concise.
Acronyms and abbreviations should be avoided because they often don’t make sense to visitors unfamiliar with the abbreviations. That being said, some abbreviations, such as http://domain.com/faq, may work so long as they make logical sense to most visitors.
If your Website has multiple users who are able to write URL path names, I recommended defining in the governance plan some limitation for who may write top-level directory names. These are typically the most highly sought-after URLs in a Website, and you will want to have a well-defined process for how those are distributed and assigned. A free-for-all is probably not a good process.Sub-Section
SUB-SECTION is the second-level directory, if one exists. Using About as an example, “Meet Our Team” is the second-level “directory” in the URL path:
since “Meet Our Team” is just one of the sub-sections under “About” in this example.
SUB-SECTION names also may be one continuous string of letters without hyphens or underscores, such as:
or a string of words separated by hyphens:
The choice between the two really depends on whether the additional words add value to the user’s understanding of location, and/or if the string of words adds SEO value because it captures important descriptive words for the content of the page.
In the example above, the words “meet our” really don’t add much information, and the shorter URL path name is simpler. Simplicity may become more important as you add pages to sub-sections and the URL path names become very long.
Some URL path names may appear to deviate from this rule if a sub-section does not actually exist, in which case the sub-section location would be occupied by the page name.Page
Pages on the “Meet Our Team” site would then have a URL path structure of:
where PAGE-NAME could be any number of different page names. PAGE-NAMEs should generally describe the content of the page based on the page’s title. This can be expressed either as a single word (if a single word sufficiently describes the page), such as:
where “consultants” is a page for information about consultants on the team titled “Consultants”; or by a string of hyphenated words, such as:
where “website-consultants” is a page about Website consultants on the team titled “Web Consultants.”
For the purposes of SEO, at the page level, I generally prefer to include all of the keywords in a page’s title (separated by hyphens) in the URL path, especially when it adds descriptive value.Sub-Page
As follows, sub-pages for any of the pages in the “Meet Our Team” site would have a URL path structure:
should follow the same rules as PAGE-NAMEs, however sub-page names may require longer strings of hyphenated names as pages become more detailed and specific:
Conversely, if sub-pages are breaking out content into simpler categories, they may benefit from shorter names:
All of that being said, you should determine the system that works best for your needs and stick to it. Just keep it simple, logical, and as memorable as possible so that it is easy for all users to implement.Multiple-Word Names
When writing URL paths with multiple-word names, I recommend using hyphens, such as:
rather than underscores:
Use of underscores makes it far too easy for a user to misread an underscore as a space, especially when the URL path is hyperlinked:
Most hyperlinks are underlined to indicate to users that a section of text is a hyperlink.
Concatenation is more obviously problematic because it simply creates confusing URL paths.Aliases & Redirects
How URL path aliases and redirected URL paths are handled will depend on the policies of your organization and the platform you use for your Website. I highly recommend you define the rules and processes surrounding URL aliases and redirects in your governance plan, and here are some questions to consider along those lines.
- How are URL aliases and redirects managed in your Web environment?
- Who manages URL aliases and redirects?
- Is there a process or procedure for requesting an alias or a redirect?
- May anyone request a URL alias or redirect?
- Are redirects to Websites outside of your domain or server environment permitted?
- Who determines whether a URL alias or redirected URL path is appropriate or not?
- Are there any special rules for using top-level directories as URL path aliases or redirected URL paths?
This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:
- Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
- Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
- Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
- Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
- Roles and Permissions – Define who should be able to do what in each system.
- Content – Understand how ownership and permissions should apply to content.
- Organization – Establish how the content in your digital properties should be organized and structured.
- URL Naming Conventions – Define how URL patterns should be structured in your websites.
- Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
- Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
- Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
- Web-Based Applications – Consider use and ownership of web-based tools and applications.
- E-Commerce – Determine the role of e-commerce in your website.
- Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
- Social Media – Set standards for the establishment and use of social media tools within the organization.
- Digital Communications Governance – Keep the guidelines you create updated and relevant.
Stay connected with the latest news on web strategy, design, and development.Sign up for our newsletter.
Latest DrupalConsole rc-9 is out including several changes and fixes.Support for command aliases
Aliases for commands added making easy to memorize by typing less. You can find aliases definition at https://github.com/hechoendrupal/drupal-console-core/blob/master/config/dist/aliases.ymlSupport to execute the DrupalConsole Launcher on Windows platform
This PR https://github.com/hechoendrupal/drupal-console-launcher/pull/51 fixes the `\vendor\bin\drupal.php` file not found error.Execute DrupalConsole from any directory within your Drupal site
No need to stay at site root directory. You can now switch to any directory as modules, themes, web/modules/custom or any other directory within your Drupal site. This was possible using the DrupalFinder project https://github.com/webflo/drupal-finder/
NOTE: Having a configuration file containing `root: web` on the site is no longer required. You can keep the file but is required to remove that value from your `path/to/drupal8/console/config.yml`Improvements on the `init` command
The interactive mode for the init command now ask you and show a list of directories where to copy the configuration files.