ebedgert

Edited to add: I am using landscape format on a regular 16:9 format screen. The scrollbars cover up a little bit of the images and video, even though I made the images the proper exact size.

Flushed the page cache on Total Cache plugin; for some reason it hadn’t updated properly as usual. Problem cleared.

Additional info: No new plugins have been installed or updated recently.

Thanks.

Some people like to quickly create little info boxes that are aligned similar to photos, so maybe you might consider that in a future version.

I’m using Aesop 1.3.2, WordPress 4.0.1, no other plugins activated. And Twenty Fourteen version 1.2.

“In short there’s no direct way to set the width on the entire content component at this time.”

So, it’s not a bug, it’s a feature I guess? (the align property apparently only refers to the text alignment? You might want to make that more clear in the properties selector for the content box.)

When I try to change the width of the content box, it changes the width of the text, but the colored background area still extends across the post.

I’m not sure where to look in those URLs for information on how to get the content box to align properly?

Is this a common problem with the 2014 theme?

Clarification: it doesn’t display on ANY page of the site, whether posts or pages.

There’s not much to see. The generated URL for weekly archives is https://www.mysite.com/?m=2013&w=34 (as an example) and resolves to https://www.mysite.com/2013/?w=34.

It’s not a child theme.

I’ve had this same problem, but it strikes (seemingly) random posts.

PHP mode did not help.

I don’t have Ad Injection on my site. Are there any other known plugin conflicts that cause this?

Not resolved, but the problem is that the code snippet to change this doesn’t work when a post’s status changes.

An update on this code snippet: It only seems to work when you are creating a post. If you create a post, it won’t auto-add anyone, which is great.

However, once you change a post’s status, people (including the author) get auto-added again, which sort of defeats the purpose I think. Is there any way to alter the code snippet to make sure that changing a post’s status won’t make the unwanted auto-subscribe behavior recur?

BTW, just adding that the code to remove “a user” from notifications won’t work in this instance, as the user entering the post is usually not the designated author.

I tried using this code in functions.php but it is still auto-adding the author to the notifications list. The behavior hasn’t changed at all.

Hopefully you will make it clearer in the documentation that this is the default behavior, because a lot of people seem surprised it does this. Or, in a future version, have an option to turn this off. (I work in a large organization where authors really aren’t part of the editorial process, they just submit stuff and don’t need to see notifications of every change to their material.)

Resolved. Problem was de_getPostImageDescription