#13476 closed enhancement (wontfix)
Switching columns in screen options make you loose all your setting in the side column
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.0 |
Component: | Administration | Keywords: | |
Focuses: | Cc: |
Description
If you go to Add Post > Screen Options and switch to 1 column, and then you go back to 2 columns,
the 2nd column (SIDE column) will be empty
The only wat to fix this is MOVE BACK every single box to where it was and never again switch to one column.
I tried to understand why was that and changes are saved via admin-ajax.
Here are the http request logs.
http://wordpress.pastebin.com/t3HKvHP6
I start with 2 cols and an empty side column, 1) I move the post-excerpt box to the side bar 2) I switched to 1 col 3) I switched back to 2 cols.
Look, in the 2nd request, order%5Bside%5D= order%5Bnormal%5D=...,postexcerpt
order[side] is empty and postexcerpt gets set in order[normal] I don't know if that is the expected behaviour, but are the original settings for [side] saved somewhere so when we switch back to 2 columns, can they be reloaded?
here is what´s saved to the database
please read the full code in php serialized format
http://wordpress.pastebin.com/VN0LYGb7
but in plain english is as follow:
#Step 0: initial stage: 2 cols, side bar empty
#Step 1: move postexcerpt into the side bar
`Array
(
[side] =>
[normal] => ALLTHEBOXES
[advanced] =>
)
`
#Step 2: switch to 1 column
`Array
(
[side] => postexcerpt
[normal] => ALL THE BOXES except "postexcerpt"
[advanced] =>
)`
#Step 3: switch to 2 columns
`Array
(
[side] =>
[normal] => ALLTHEBOXES
[advanced] =>
)
`
#Step 4: reload page:
`Array
(
[side] =>
[normal] => ALLTHEBOXES
[advanced] =>
)
`
It is clear that once you switch to 1 column, everything in the SIDE COL is moved to the end of the NORMAL COL, and all the changes are lost and switching back to 2 columns wont do anything.
this is happening in wp3.0-beta2
Change History (9)
#1
@
13 years ago
- Keywords reporter-feedback added; screen options side column ajax removed
- Milestone changed from 3.0 to Unassigned
#2
@
13 years ago
Yeah, it's mildly annoying, but I don't believe it to be a bug. Azaozz did the code on this originally in 2.7, I believe. But isn't all the screen position stuff just stored in a cookie anyway, not something that is saved in WP itself?
#3
@
13 years ago
- Milestone Unassigned deleted
- Resolution set to wontfix
- Status changed from new to closed
Having to move everything back is by design. The user can show/hide menu boxes and do other modification in between changing the number of columns. Tracking and merging these changes is not worthwhile.
#4
follow-up:
↓ 6
@
13 years ago
Look at it from a USER pespective.
Wordpress is supposed to be intuitive and friendly.
Will you ever think that after checking a radio button to see how it looks that feature, and checking back the original because you didnt like how it looked, you will have to move every single box you had on the right?
No warnings or anything is offered,
no submit buttons to really confirm this change.
From a user experience point of view this IS A BUG!
why not have two different settings, one for two columns,
another for one column
#5
@
13 years ago
- Component changed from General to Administration
- Milestone set to Future Release
- Resolution wontfix deleted
- Status changed from closed to reopened
- Type changed from defect (bug) to enhancement
I am changing the status as i think if its closed i wont get the attention needed.
I changed the properties to Future Release and enhancement, but i am pretty sure someone may be insterested in working on this.
i tried to msg you ryan but there i no way through the system, to ask you about if its ok to reopen it.
sorry, i am breaking some rule, im new here.
#6
in reply to:
↑ 4
@
13 years ago
Replying to wjm:
Will you ever think that after checking a radio button to see how it looks that feature, and checking back the original because you didnt like how it looked, you will have to move every single box you had on the right?
You shouldn't be hiding the second column if there are postboxes in it in the first place. Moving these postboxes to the first (main) column is a failsafe. If the used intends to test one column layout, the visible postboxes currently in the second column should be moved or hidden beforehand so it's empty. The same applies for the Dashboard.
We probably could add AYS there, something like "The column you are hiding is not empty. All elements will be moved to the next visible column." to cover cases when playing with (testing) this functionality.
#8
@
12 years ago
- Keywords reporter-feedback removed
- Resolution set to wontfix
- Status changed from reopened to closed
@wjm: Say you switched to one column to see how it looked, changed the order of where the boxes went (i.e., dragged tags to be above/below categories etc), then switched back to 2-column layout. Which order would be restored? The action in the first column set a user-desired placement. Should that be overridden to return to a previous state? There are too many possibilities here.
I don't see how this is a bug. If you convert from two columns to one column, then all objects in the second column get moved to the first. If you go back, it does not remember where they were, because it does not store that.
Is there a bug here that is not what I described?