Hiding page titles

There is now a page option available to hide the default H2 heading on pages. If you primarily use our content blocks feature for advanced page layouts, this feature was already in place (a page using content blocks must have a heading manually added to the content). For pages using the newer Gutenberg editor, you now have the ability to hide the name of your page, which allows you to use a Gutenberg block at the top of the page with more advanced heading options.

To hide a page’s default heading: when editing a page, display the settings panel by clicking the gear icon in the upper right of the Gutenberg editor (this icon toggles that panel to display or hide). Within the settings panel, select the “Page” tab and scroll to the bottom of the panel. There will be a “Page Options” section where the “Hide page title?” checkbox is available. Checking that box will hide the default H2 heading on your page.

Important note: All pages on your website other than the home page should have an H2 heading at the top of the page for search optimization and web accessibility compliance. When turning off a page’s heading (or when using content blocks) it is important to add a text heading to the page to characterize the content on the page for site search.

Hiding sidebars on posts

The Gutenberg editor is also available on website posts; because posts are typically text-heavy content pieces, the page sidebar has been a part of the post template in order to narrow the column of text for readability. For those who want a cleaner reading experience for their posts, there is now a “Post Options” section in both the Gutenberg and Classic post editor where you will find a checkbox, “Hide sidebar.”

When a sidebar is hidden on a post, the content area for the post remains the same width, but is now more centered on the page with wider margins to each side.

Important note:  If there is important content in your sidebar, hiding the sidebar is not advised.

Importing events into website calendar

We license a “content aggregator” feature for our events calendar software, which works to import events in a shared Google calendar as event web pages you may list in a umaine.edu calendar list content block. This feature stopped functioning for our websites in mid-January. Our team has been working with the software vendor to identify and resolve this problem, but as of this newsletter the issue is ongoing.
The workaround is to manually create events within the WordPress calendar feature.

“Repost to 91¸£Àû News” and “Repost to 91¸£Àû Calendar” feature

Our website has a content syndication feature for news and events— if you view a published news post or event detail page, the WordPress “admin toolbar” at the top of the page has a text link that states “Repost to 91¸£Àû News” or “Repost to 91¸£Àû Calendar.” This feature creates a copy of your post or event, and submits it to the appropriate website in an unapproved “incoming” state for Marketing & Communications staff to review and publish.

Recently this feature has incorrectly given an error when it is used: instead of stating “Reposted” the message is “Try again? Failed to repost to” for either 91¸£Àû News or Calendar. The content is still being copied over, but because of this error your own site will not indicate that this has been done.
The workaround is to not believe this particular error message when you see it. We hope to have this issue resolved soon.