In crafting your landing pages through hard code, you will most likely be using sections. As per the HTML5 doc, it is recommended to use sections:
The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.
— W3C WD HTML5, The Section Element
So why not semantically call them
section rather than plain
div elements? That way, your code will be organised in such a way to semantically progress to using ID attributes, as mentioned below.
Using ID attributes can extend your sections with anchors, like those you see on a table of contents.
Ideally, you will want these for headings, but since you are focusing on landing pages then the flow of the page would be sections.
Now with the ID attribute uniquely identified, you can make use of this by adding a URL that ends in
#download, and your page will jump to the download section. This fashion can further be extended by partialising your sections, so that they can be reusable. However, you have to be careful to make sure that the section will not have any changes.
In my experience it has been that the sections do change. So the best solution I could find thus far would be to continue with the partialisation, but name the partial as
section-download-3bdc.php. This naming convention uses the following system:
- Parent element
- GUID (random string)
For the most part, you will have your Parent element as section. The ID will vary depending on the classification of the section. And the GUID is a way to uniquely identify a subset of the classified section. Since you might fork a section and carry a different version of its own. I have opted for the use of a GUID since it avoids from thinking about what to name the fork of the section, since it is not that necessary to name the fork descriptively.
Of course, this does not restrict you from re-organising your child elements in such a way that they still hold similarities between other sections further down the line. For example, if you would like to re-factor your
section-download-*.php files to include a new component.
In naming your section ID value, it is best to follow a lowercase hyphenated naming system. For example,
download-now, as opposed to other conventions such as camelCase
downloadNow or lowercase underscored
download_now. In the eyes of Google and the search engines, however, they are able to identify underscores as word joiners, so opt for the lowercase hyphenated naming system instead.
Also, if you would be having a phrase as your section ID, then your filename would be something like this:
You can see that the underscore was used. This is that the use of hyphens is the separator, whilst the underscore is still the joiner between the two words.
This goes with the convention stated earlier to style components unique to your certain section with CSS classes, not particularly IDs. This is significant as it exhibits the BEM methodology, where you keep all blocks within the same specificity, that is using 1 class only, unless absolutely necessary with the weighted risks involved.
You may follow it this way, wherein the CSS class uses the naming convention
section-downloadNow. Of course, it is up to your preference whether to use camelCase (in my opinion it is more readable) than using
section-download-now. Since, in my preference using the hyphen
download-now seems to be read as
now being a subset of
download albeit ‘download now’ is a single phrase. The reason in doing so is that if you were to have a subset of
downloadNow, then you could add a hyphen to it, and it would be more readable that way.
Now it goes without saying that CSS can easily become messy really easily, if no conventions are set in stone for the project. A good advocate to clean, reusable, maintainable, and scalable CSS code is Atomic CSS. This follows building utility or helper classes, to make your CSS code reusable.
— Adam Wathan, CSS Utility Classes and “Separation of Concerns”
In the example above, a CSS class has been added called
padding-m. And it has one purpose: to provide
padding-bottom to the element from which it is present upon. This can be further extended to have the ‘medium-sized padding’ differentiating on different device widths through
@media queries. Thus making the
padding-m truly a utility!
Of course, you can also add
padding-xl to signify extra sized padding to the element. And that these would have differing media queries of their own depending on their scale. But for the most part it seems to be ideal to provide your sections with adequate padding between themselves.
One tip to avoid is providing padding to your
section element in general. Since we have already established a convention to use CSS classes only in providing styling. Of course, if all your sections in the foreseeable future are to be padded out, then by all means that is alright.
To be doubly sure with this aspect, you will want to implement CSS code in such a way that you include
The above code signifies that a jQuery selector of
js-slideIn would display a slide-in animation. If you were to view the HTML of the code, it would appear as follows:
js- selectors, you can do so with CSS. The only thing to make sure is that you have to understand that
When working with landing pages, you may opt to use custom fields.
The philosophy behind the use of custom fields varies depending upon the scope of the landing page(s).
For example, there can be 2 kinds of landing pages that might require custom fields:
- landing pages that have the same structure, but different content/shortcodes
- landing pages that will require the input of additional content, in the case of FAQ accordions.
For the most part, only use custom fields when it is explicitly mentioned to have them included within the project. If it is only assumed to be used, then do not use them at all, as is the case with project creep. It is very easy to continue to provide extra features in the hopes that the project would become more dazzling in its features. However, this can easily turn into a nightmare when it was only assumed to make use of custom fields. Only to find out that custom fields were to be removed every now and then in some templates, but not others, etc.
A good use case of using custom fields is when the landing page would require a gallery of images. First of all, this provides the ability to implement more gallery images for the landing page template. Secondly, since the gallery images are being referenced through WordPress custom fields, then within the landing page PHP template we can make use of
wp_get_attachment_image() function to provide the browser with responsive images, currently with the use of the
This gallery of images can also be used for a carousel, or a slider of images too. Since there would be many images implemented onto the landing page, it would be ideal to have them as responsive images to encourage faster loading times. It does not cost the Earth to implement this procedure. But it is important to understand the implications of adding custom fields which have been discussed so far within this article.
Again, please do not go overboard with the use of custom fields unless absolutely necessary. As in, explicitly mentioned within the project scope to include the use of this. The only downside to using custom fields though is that you will have to check that the addition of this and for the near future of the project would be that the custom fields would keep the landing page templates maintainable, scalable, and reusable.
A popular WordPress plugin from which to use custom fields would be Advanced Custom Fields PRO. This plugin provides almost every custom field necessary, and if not, there are still a wide variety of add-ons by other plugin developers to provide this.
The best procedure so far in implementing advanced custom fields would be to create Field Groups per section, and create a condition to display the field group for a certain template. That way, you can create another OR condition to display the same field group in another template if necessary. This is in contrast to creating 1 Field Group containing different fields, of which would be more difficult to import/export if and when the time arises.
The naming convention of the Field Group could be set to the name of the section that it is intended for, e.g. Download Now Section. And its accompanying fields within the field group could be named as title, description, CTA. If you would like to make use of Group fields, you can gladly do so, as its intention is to further organise your custom fields, should you need a second field group further down the line in your sections.
When creating a variation of a section, such as
section-download_now-3bdc.php, you will have to create a duplicate of an existing Download Now Section field group, and display this on the certain template from which it would need its data. This way, you are still utilising the same method by forking the field group, and taking on a new path from there.
Now that you have learned the above techniques in crafting your code. You can identify the following techniques in getting your landing page code in tip-top shape. That is, with scalability, maintainability, and reuseability in mind. Think of the DRY (Don’t Repeat Yourself) principles. In effect, the following techniques have been discussed:
- Specify a convention, and stick to it for the lifetime of the project until refactoring
- Use sections in your landing pages
- Add IDs to your sections
- Partialise your sections for reuseability
- Use separate
- Use custom fields if explicitly mentioned in the project brief
- Follow the DRY Principles — Reuseability, maintainability, scalability
If there might be any comments or questions with regard to the structure and methodology with coding landing pages, please let me know in the comments below! I would be glad to join a discussion with landing pages. So that an even better thought process can be discussed!