This page contains the following handy tips for creating and editing pages in the LLIR website.
Allow for different renderings of the page
Switch quickly between editing and testing a page
Return quickly to the WordPress dashboard
Avoid Tempting Shortcuts for Creating Content

Before you continue:
If you are new to this development platform, read the Overview of our Platform.
If you are not familiar with the basics of WordPress and the Guttenberg editor, you may benefit from watching an online tutorial.
For help getting started with the editor, read Learning the Page Editor.

Allow for Different Renderings of the Page You are Editing

Whenever you modify a page, test by viewing the page as a user before spending a lot of time trying to adjust details of page presentation. This guideline applies especially to changes that affect the page structure, including adding or moving Headings, Paragraphs or any other type of editor block. In other words test all changes that affect editor’s Document Outline panel. Also test text highlighting. The next section of this page suggests a way to switch quickly between viewing the page as an editor and as a user.

Explanation: The Guttenberg Editor generates HTML files for web browsers to display. Each web browser and HTML editor includes code for rendering (parsing HTML code and displaying the document). Rendering is specific to each tool so the same page may look different when the user sees it from when you edit it. Rendering algorithms mostly adhere to industry standards, so the differences are sometimes subtle.

Here are some ways that different pages may look different depending on the editor or browser in use:
The amount of white space below the page header, between blocks within the page and around images.
Guttenberg does not always display text highlighting, especially when Kadence and WordPress blocks are nested. Sometimes Guttenberg just indicates highlight colours in the Editor toolbar.
Web browsers on mobile phones take considerable liberties with the layout of multicolumn blocks, such a menus and Row Layouts to adjust to screens that are taller then wide.

Switch Quickly Between Editing and Testing a Page

Always test after editing a page. Unless the change is spelling or minor rewording, you should look not only at what you modified but also for potential undesirable side effects such as broken links.

This section describes a process that makes switching between edit and test fast. It also works around drawbacks that occur when you click Save to update the page and then click View Page to verify the result:

Because the View Page link replaces the content of the browser tab in which you are editing:
You can return to the editor to continue editing by clicking the browser Back button, but sometimes doing so requires many clicks or you end up opening a new editor session.
You remain logged in as an WordPress administrator, not a regular member. A public page appears under the Member Header and you cannot test for links from public pages that break login security by opening member-only pages.

The overhead of the following method is the first two steps below, but they save time when you go back and forth between edit and view modes while working on one page. If you have two screens, the ideal situation is using one browser on one screen for viewing and and your preferred browser on the other screen for editing. The second browser and second screen could be on your smartphone

Open the page for viewing on your second screen.
If it is a public page use a different browser from your preferred browser so that you are not logged in.
Login to see a member-only page. If you have only one screen and dislike stacking windows, you can use tab of your preferred browser for viewing.
Go to the WordPress dashboard in your preferred browser and open the page for editing.
When you complete a set of edits, click Save . Wait for View Page to appear but do not click it.
Switch to the other browser or tab and click the Reload button. This button is usually a circular arrow to the right of the Back button.
Make sure that the updates appear and the page is correct, including that links work.
To continue editing, return to the editing tab on your preferred browser.
Repeat steps 3 to 6 as often as you want. Note that all editor panels remain open when you switch back and forth.
When you are satisfied, close both the editing tab and the other browser.
Your changes are already saved and the page may have been tested on a second browser as a bonus.

Return Quickly to the Dashboard

Here are two suggestions for opening the dashboard quickly.

Create a browser bookmark for the dashboard. Whenever the bookmark is visible, you can return to the dashboard in one click.
Change the address in the browser location bar to read: llirto.ca/wp-admin. If you want to keep the current editor open at the same time as the dashboard, enter the dashboard address into a different browser tab.

Avoid Shortcuts that are Temptations

Page authors are advised to build page content from scratch and to do so using only the blocks types provided by the WordPress editor and our theme. Do not be tempted by two practices, described below, that WordPress allows but that you are likely to come to regret in the long term.

Don’t Use WordPress Templates to Build New Pages

The Kadence comes with an extensive list of Starter Templates that are examples of webpages and websites built with Kadence. Feel free to browse the template library to get ideas and see what is possible to build. Find the template library from the Dashboard by clicking Appearance, Kadence and then Starter Templates.

Importing pages and then editing content is easy and tempting but is not a recommended to build new pages. Avoid adding imported pages to the LLIR website. The reason is that the samples come with their own styles, colours and customizations to the theme. When you import a page from another website, that websites styles override LLIR settings on the imported page. You cannot see or remove the imported settings using the visual editor and editing some blocks that appear on the page may be impossible. As a result, imported contain pages don’t match the look and feel of the the rest of the LLIR site. A much better approach is to learn how to build the sample page that you like from scratch.

Exception
The LLIR website contains one page that was imported from the starter templates: the public Contact Us page. This page includes a form that, unlike all other forms in the website, is not connected to the LLIR database and backend code. Instead it imports a set of form building blocks from another website. In addition to adding the overhead of these blocks, the result is a form is very difficult to edit and a page with styles that are are close, but not identical, to LLIR styles.

Avoid Coding Any Page Content in HTML

Do not insert HTML tags into webpages, even if you are so comfortable coding HTML that you find low-level tagging easier or quicker than mastering WordPress and Kadence blocks. There are two main reasons:

A minor typing error in raw HTML or a combination of tags that may be legal HTML but that the editor does not recognize can result in a page that the editor cannot parse. In extreme cases, the the page may be so corrupted that browsers cannot display it and the contents are virtually impossible to fix.
Even if the contained HTML works now, future webmasters may not be able to maintain the page.

Note: The Editor provides two block types that support HTML: Custom HTML and Dynamic HTML. If you absolutely must insert some HTML enclose it a Custom HTML block so that the editor can tell where it starts and stops. Dynamic HTML is beyond the scope of these notes.