jeremyjaymes

Thanks for the reply. I want to keep it simple and useful at it’s core but I love the idea of expanding the scope of this plugin in this way. Like I said, I’ll have to think about the best way to do this and then experiment a bit to determine the best approach. No guarantees on completion or timeline but I’m definitely on board for trying.

Just to clarify something quickly, I assume the Portfolio type you speak of is a custom post type. Perhaps one that is built into the theme you are using?

Thanks, glad you find it useful. So, if I understand you correctly I think I like the idea you’re suggesting. Basically you’d like to be able to enable/disable page labels for any post type – custom or built in?

I’m sure it can be done but I’d have to give it some thought, last thing I’d want to do is overcomplicate it. Thanks for the suggestion!

@avery1 – I apologize for the long long delay in answering this question, I either didn’t receive notification of the question or the notification went to spam.

Anyway, I doubt the answer will be useful to you at this point but thought I’d answer either way in case it helps someone in the future.

Technically it could be used in the way you are suggesting if I understanding the question correctly. The plugin stores the label as a custom field so it could be accessed from within a template. That’s said, it’s not really the intended use for the plugin so it would probably take some work. The plugin is more meant to allow one to organize pages on the back-end using simple labels when the page titles might not be obvious.

Hopefully that answers the question for someone in the future.

Resolved for now.

Good advice, I’ll take a further look at the few plugins I have running to see what I can find. I do have BruteProtect running and I’m starting to wonder if I might have set something there.

To answer your question, I did not receive the auto-update email, that’s part of the reason I posted here. I assumed right away that it was something other than core (probably should have stated that) and was hoping to see if anyone else experienced the same thing, perhaps helping me to narrow it down.

Regarding hosting, have a few other installs running on the same machine that did not auto-update. To my knowledge Linode is pretty hands off on that type of thing, they pretty much put you in the drivers seat.

Just to be clear, I do not or did not consider this to be some sort of a bug, I’m sure I’ll find that it’s self-inflicted. To be totally honest I’m starting to wonder if perhaps I ran the update myself in some sort of a sleepy haze before I signed off for the evening.

It’s a mystery. Good news is that the update itself caused no issue.

Thanks to everyone that added their comments to this thread, I’ll go ahead and mark it resolved for now. If I find the culprit I’ll post back.

@matthew – I’d prefer not to disable core updates. I’d like it to run minor releases as usual but want to maintain control of major. I’m guessing that you are correct it is probably due to a plugin although I don’t run many. Less likely but possibly due to something I’ve added to my theme and just don’t remember. My goal here is to see if anyone else has seen this happen so maybe we can compare plugins or something.

@wpyogi – good suggestion, unfortunately I’m not on a managed host, unmanaged VPS.

I’m open to any other ideas, really appreciate how quickly you both jumped on this ticket.

Also, to answer your question – I did check wp-config just to see if I’d enabled it for some reason in the past but no luck. I intend to dig deeper when I have time today but as of right now I don’t remember enabling anything intentionally.

Thanks for your feedback.

Correct, and that was my understanding until I awoke this morning to find OSSEC alerting me to a handful of core files being changed. Logged in to find that my site had been updated to 4.1. Unless I’m sleep walking there has to be some reason so thought I’d open a thread to see if others have experienced this.

That post is exactly the post I was referencing, seems like they’re asking the same question but so far that’s the only other report I’ve found.

It looks like you’ve dropped the box shadow on #access correctly in your child theme. However there’s a minor error in your child theme stylesheet so your #access modification isn’t actually being recognized. See #branding .only-search #s and notice that you are missing the closing bracket.

As for the header width, what WPyogi is suggesting should put you on the right track, you’ll probably also need to look at modifying your #main and #primary elements depending on what you are looking to do.

Is the actual input field on “store uploads in this folder” blank followed by the italic text “default is wp-content/uploads or is there something entered in that field?

If it is blank try entering wp-content/uploads then save changes.

keesiemeijer is probably correct, you likely need to check your “store uploads in this folder” under Settings > Media because if you have a look at the source on the url above the header image path looks like this:

https://www.portablevalveactuator.com//2011/07/Header_Valves2.jpg

it should look like this (you can enter the following url and you’ll see your image):

https://www.portablevalveactuator.com/wp-content/uploads/2011/07/Header_Valves2.jpg

Notice that the image path as it is currently set is missing the “wp-content/uploads” part.

Are you maybe looking for Post Thumbnails?

Have you checked the current widgets under Appearance/Widgets (Admin). It more than likely appears there, simply drag it out of the sidebar and to the left.

I wouldn’t recommend editing the single.php, I am assuming the structure there is correct. Sounds like the blog content plugin is importing a closing div with the content itself. It could either be a situation in the plugin or it could relate to the content being imported. I would start by troubleshooting in those two areas before editing the template files.

No worries, looks like the problem is fixed?