Helen Hou-Sandi

UI could be nice if you think it’s a common usage, but a filter is a pretty quick change and would be a good idea anyway, for devs who need to control across environments without having to set up the plugin via UI every time (e.g. local, staging, and production).

Please don’t change the plugin code itself – there are hooks provided for you to alter behavior. Altering a plugin or theme directly is never a good idea, as your changes will get wiped out with an update. This should work, in something like the theme’s functions.php file (if it’s your own theme) or a custom plugin file:

add_filter( 'rsgw_query_args', 'hhs_attachment_page_rsgw_query_args', 10, 2 );
function hhs_attachment_page_rsgw_query_args( $query_args, $args ) {
	global $post;

	if ( 'attachment' == get_post_type() && ! empty( $post->post_parent ) ) {
		$query_args['post_parent'] = $post->post_parent;
	}

	return $query_args;
}

I’m not sure what you’re asking here – the image sizes are what are registered in WordPress. Perhaps it has to do with styling? The markup was changed a bit in 1.2.

Yes, markup was changed to be more semantic, especially with captions. It’s modeled after default themes like Twenty Twelve. It was noted in the changelog and the upgrade notice for 1.2.

Just tagged 1.3. If it doesn’t show up for update right away, give it a few minutes. Let me know if it solves the issue.

Okay, my suspicion is correct ?? I added some extra data sanity in 1.2 and it assumes that image sizes are named key-style; that is, all-lowercase without spaces. I’ll change it so it doesn’t make that assumption anymore.

What is the theme’s custom image size named? I have a suspicion about what’s going on, but not completely sure.

Should be fixed in 1.2.

Can you provide a link to a site where it’s not working? If you’ve stopped using the widget in the meantime, that’s okay, too.

Dumb mistake on my part ?? The 1.2 update should fix this.

I’m actually able to reproduce this behavior in 3.4.2, whether or not both editors have galleries. It happens in a pretty specific series of events, so I would guess that it was there in 3.5b3, just unnoticed.

It looks like the buttons can appear overlaid on the wrong editor, and if you go and click those buttons that appeared in the wrong place, you get the set associated with the placeholder that you first clicked. 3.4.2 doesn’t show anything differently in the media modal, so it’s not noticeably wrong (although I presume it would actually change settings for the wrong one), but 3.5 does show differently, so it’s much more noticeable.

I’ve written up and submitted a Trac ticket for it: https://core.trac.www.ads-software.com/ticket/22785. For the time being, double-clicking the placeholder you wanted seems to do the trick consistently.

I think this thread has now diverged from the original topic – which is one that is related to CSS in WordPress core software. xiexiema, SGallay, and Fashiongeekette – it sounds like your issue is Jetpack-related, and not CSS in WordPress itself (which wouldn’t have just altered itself spontaneously).

I just tested Jetpack myself and it seems to be the issue. Here’s a relevant thread: https://www.ads-software.com/support/topic/plugin-jetpack-by-wordpresscom-problem-with-the-admin-css-jetpack?replies=5

What happens if you scroll horizontally to the right? That’s when the overlapping happens for me. Just tested again in my trunk install.

I’m on OSX, looked at both Firefox and Chrome. Can’t remember what version – probably trunk. I do a lot of core UI things, wanted to see what was up with that ticket ??

Howdy everybody,

I wasn’t directly involved in this change, but I’ll speak to as much as I can and try to clear up some confusion.

There was indeed a change in 3.4 involving making the Dashboard and Write/Edit screens responsive, that is, adaptive based on the screen size (it seems that those of you posting here know what that means, but I just wanted to be thorough). If you’re interested in how that came to be, you might take a look here: https://core.trac.www.ads-software.com/ticket/20015. Note that this ticket is closed on a released version, so please don’t re-open it.

What I’m seeing is that it jumps directly from 4 columns to 2 and does this on all browsers based on the window width, which is of course what responsive media queries in CSS do. There is no middle ground where you can have up to 3, and it does not take the collapsed or uncollapsed state of the admin menu into account. It’s worth noting that currently the admin menu will collapse itself and doesn’t have an option to expand again at a certain width. These are all impartial statements of observation – I am not passing judgment one way or the other.

WordPress is an actively developed software, which means that we have the ability to keep making improvements/enhancements as we find things to improve upon, in addition to adding features and fixing bugs. For example, I know that I’ve already seen a request from a lead that the admin menu be able to un-collapse even if it’s been auto-collapsed by CSS, which sounds reasonable enough and can be worked on by anybody who wants to contribute back to the software project on the development front.

So what are our real options here? I see the following:

• That there be a middle ground where 3 columns can show on the Dashboard instead, and perhaps also some refining to account for the state of the admin menu.
• That the columns still auto-arrange if you haven’t selected a particular option yet, e.g. an auto option, but allow you to choose another if you so desire and remember your selection. This was actually tried in 3.3 and had some really funky side effects, if I remember correctly. Maybe worth another shot, maybe not. I foresee issues where somebody generally likes 4 columns at home but then has to switch to 1 on their mobile, and then has to keep switching every time they change devices and loses placement of their various widgets/boxes. It’s hard to balance, and WordPress’s core philosophy does tend toward making decisions rather than giving too many options and building for the majority, while trying to listen to what some might call the “vocal minority”.
• Making a plugin that reverts back to old behavior, or even tweaks existing behavior for now. Advantages here are being able to use it sooner than a new version of WordPress would come out and that it would get more widespread testing and could actually inform how the core software ends up behaving. Disadvantage is, of course, that you have to install a plugin. But sometimes for a smaller percentage of users, it’s a better way to go.

All of that said, I don’t think we need to treat these changes as though they are a personal affront or get too agitated about them. I understand that things are (very) frustrating when they don’t act as expected, and since forums are all volunteer- and fellow-user-based, sometimes folks don’t have all the information. I don’t have all the information, either ?? What I can do is try to figure out whether or not there’s something we can do to make this better for the majority of people.