bvbaked

.port-image > iframe {
    width: auto;
}

.port-image > iframe,
.port-image {
    height: auto;
}
			
body .post_content .port-image > iframe,{
    width: auto;
}

body .post_content .port-image > iframe, 
body .post_content .port-image {
    height: auto;
}	

I’m seeing this little snip of CSS added via an inline style that is causing your problem. The images are served via a CSS Background, therefore have no intrinsic height – setting that to auto means it collapses.

I’m guessing it was added because the iframes for the videos look a little odd at that height?

.port-image {
    height: 150px;
   
}
.port-image > iframe {
    width: auto;
}

.port-image > iframe {
    height: auto;
}
			
body .post_content .port-image > iframe,{
    width: auto;
}

body .post_content .port-image > iframe {
    height: auto;
}	

If you change it to that, you’ll see your images showing again, but you may need to finesse the styles a little more.

Sounds like you may have removed the hover state then?

What threadi suggested would only need to be applied to the first bit of your CSS

.menu-incident a:hover {
background-color: #ff8a42;
color: white;
}

This can remain unchanged since it seems like that is working expected.

Your first selector was getting overwritten due to specificity though, so you needed to add a selector for the default state

Does having a media library of that size, when we’re only using maybe a hundred or so of the images on the site, have any cost (e.g, slowing things down)?

As you are now aware, when you want to move the media library around it does.
For the front-end experience though, it should make things faster or have little effect. As mentioned previously, they are created in order to serve a proper image size for the space it is presented in. So if it is done correctly the images displayed will be the of the optimal size and should result in smaller files getting served

Of course, it might not be done correctly and you still just serve the full image. Having the files and not using them wouldn’t slow the site down though, it’s just a lot of extra files

Based on the context, it sounds as if you are updating a plugin and the environment is just not supporting it. If plugins are managed via composer, and you are getting this error, they may be missing due to an incomplete run of your composer install.

You should really check and update your PHP version though if this is failing. even PHP 8.0 is end of life and 8.1/8.2 are on their way out. I’d recommend getting it up to PHP 8.3 so you actually are running a supported version which should also in turn fix his error and get your plugin installed

The first thing that jumps to mind would be to make the post private or password protected. Both options would prevent the general public from viewing the content but give a slightly different experience.

With a private post, you’d require a login to view and therefore you can control member accounts via a paid option. Pros: You’d have control over who can see these pages over time, like a subscription service, where users can come and go. Cons: You’s need to have additional member accounts created and the page would just 404 instead of alerting that it is paid content for non-members

For a password protected page you don’t necessarily need member accounts but this would involve some other method of receiving payment and distributing a password. Pros: The public could still see there is a page at any of these links, but they need to pay to view it. Cons: You’d need to distribute passwords and they’d likely all have to be the same. This could lead to errors by making a typo and restricting access when it should be granted. This also means you wouldn’t be able to turn off access in the future to specific users

I’m sure there are other ways, but these would be a couple of options to consider

That page in particular should be using archive.php, but it is likely not where you’d want to add that div.

You should have a header.php file instead where the actual header gets added – that way you would have this div on every page and not just your archives. You would then hide the div with css, using a media query, on screensizes you don’t want it to display

.your-div {
    @media ('min-width: 768px') { display: none; } 
}

That should suffice to keep it off anything larger than a tablet, but you can decide what size you’d like.

If you’re in doubt of where to look, see if you can search for where the masthead or site-branding elements are added since those are in your header element and about where you’d want to place this div

:shrug:

Maybe you fixed it already, but it seemed to work when I tested it