## Description

In the last update, we changed the CSS responsible for hiding the default page title to include the condition that the hero content include an h1. This is because many sites are forgetting to change the heading in the hero to the proper tag, resulting in poor accessibility.

```css
.ua_minerva .ua_page_header:has(h1) ~ .ua_page_content > .ua_layout--standard h1 {
  display: none;
}
```

However, it's possible for this to fail if the settings were changed so that the page title is set to a different width before the hero content is added. This allows two h1 elements on the page and prevents editors from accessing the Page Title controls since the hero content hides them.

## Expected behavior

The page title should always be hidden if the page header contains an h1, regardless of other settings involving the page title.

The editor UX is a little confusing now that there is this extra condition for hiding the page title since it is now technically possible for the Page Title and Hero to exist simultaneously, although doing do does not look good on the front-end.

## How to reproduce

Steps to reproduce the behavior. For example:

1. Create a new page
2. Add the Page Settings block
3. Change the Page Title to Wide width
4. Save
5. Add Hero content containing an h1
6. Save and view the page to see that the page title is still displayed

## Additional information

I think there's 3 problems that need to be addressed:

1. The Page Title, when paired with a Hero is missing spacing. It might be a good idea to add an extra class to the page title wrapper in the page templates with a class like `ua_page_title`. This can be targeted to add margin-block-top.
2. The Page Title doesn't hide itself reliably. If we're adding a class name to the wrapper, we could use that in place of the standard width class we have now, which should resolve this.
3. The Page Settings block needs help text that explains the Page Title will be hidden if the Hero content contains an h1, and the Page Title controls should probably remain visible even when Hero content is enabled. Ideally, we would hide the controls if the Hero contains an h1, but I don't know if that's something we can do.

We may also need to update the theme docs on web.ua.edu. I don't know if it has outdated information about this behavior somewhere.


Page Title Unexpected Behavior

Closes #667 

How to test 
1. Add a Page Settings block to any page
2. Save and refresh the page
3. The "Save" button should not be enabled on a fresh page load
4. Click the "Sidebar Content" checkbox
5. Select "Dynamic" sidebar type
6. Save the page and verify the dynamic sidebar appears on the front end
7. Uncheck the "Sidebar Content" checkbox 
8. Save the page and verify the sidebar no longer appears on the front end
9. Check that other Page Settings functionality works as expected

<img width="1717" height="886" alt="Screenshot 2025-09-16 at 12 40 24 PM" src="https://github.com/user-attachments/assets/8687e4b7-8110-4c88-85d3-8d05a19cb0e3" />


fix page settings async function and sidebar display

So far I've noticed two issues with this block: 
1. When the block is on the page, the "Save" button is always enabled, as if there have been changes to the content, event on a fresh page load. 
2. If "dynamic" sidebar has been selected, then unchecking the sidebar box does not remove the sidebar from the front end.

Page Settings Block Issues

## Description

NEWLY CREATED sidebar menus are no longer appearing under the Sidebar Content dropdown. The dropdown only shows older created menus. 

## Expected behavior

When a new menu is created, it should become immediately available under the "Sidebar Menu" dropdown of the Page Settings block. 

## How to reproduce

Steps to reproduce the behavior. For example:

1. Go to any theme running version 3.2.4
2. Create a new menu for testing
3. Attempt to add the new menu under the page setting block.
4. See issue

## Technical information

- Operating System: OS X 10.15.7 64-bit
- Browser:  Chrome 125.0.0.0
- GA Supported: Yes
- Cookies Enabled: Yes
- Browser Size:  1920 x 934
- JavaScript Enabled: Yes
- Browser User Agent String: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36

## Screenshots

In this example, a new menu was created called "new menu test." However, only menus created an unknown time ago are available within the dropdown.
![menubug2](https://github.com/user-attachments/assets/3c38751c-7423-4f58-9e95-fadc61666602)
![menubug](https://github.com/user-attachments/assets/2748740b-96e8-4fc6-9699-60590a2cfd6b)



Sidebar Menus Not Showing On Dropdown [Pantheon exclusive]

## Background

Heading text wraps by individual letter on certain screen sizes rather than some form of intelligent wrapping.
Visible within this section on afford.ua.edu:

![textwrapping](https://github.com/UA-Stratcom/ua-theme_v3/assets/110553212/53e894da-0535-422b-becc-68843914efce)


## Description

A plugin to determine best-case hyphenation and wrapping, or enabling the \&shy; character or \<wbr> element within the WordPress code editor for manual insertion 

## Workarounds

No current workaround available/known

## Additional information

Related issue: https://github.com/UA-Stratcom/minerva/issues/179


Known Issues

Open Issues