WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 7 weeks ago

#32655 reopened defect (bug)

Don't save screen options (table column) in post edit page and maybe other pages

Reported by: Juriy Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.1
Component: Administration Keywords: bulk-reopened
Focuses: Cc:

Description

I fixed it so...
wp-includes/user.php
row 364

if ( $user->has_prop( $option ) )
	$result = $user->get( $option );
elseif ( $user->has_prop( $prefix . $option ) )
	$result = $user->get( $prefix . $option );
else
	$result = false;

----

	//todo bag user options delete this
//	if ( $user->has_prop( $prefix . $option ) ) // Blog specific
//		$result = $user->get( $prefix . $option );
//	elseif ( $user->has_prop( $option ) ) // User specific and cross-blog
//		$result = $user->get( $option );
//	else
//		$result = false;

Change History (6)

#1 @dd32
4 years ago

  • Component changed from Users to Administration
  • Type changed from defect (bug) to feature request

If I understand correctly, you want the screen options to revert to defaults every time the current cookie is lost?

To me, that doesn't seem like a very good user experience, and it should show what the user had selected previously.

#2 @Juriy
4 years ago

My English is not very good, sorry.
I'll try to describe in more detaily.

I mean when I choose columns to be displayed in the menu options (page edit posts) but those changes are not saved. After refreshing the page options are set as default. As I understood WP function 'get_user_option returns wp_<options name> to me and in the moment the columns choosen by me in order to hide are saved in <options name> without the prefix wp_. in the table WP_User_meta. I have corrected the function as described above would it be right?

#3 @dd32
4 years ago

  • Type changed from feature request to defect (bug)

Ah my mistake.

Checking the non-prefixed option, like you're suggesting, isn't correct, and the way Core is currently doing it looks right to me.

First it checks if a prefixed item is set, and uses that if it is, if not, it then looks for a non-prefixed one and uses that.

The prefix is for Multisite & Shared user tables. Do you have a blank/empty wp_<option> set incorrectly which is overriding it?

#4 @Juriy
4 years ago

Yes, I have two options with wp_ and without wp_. (I do not understand why)
I use Wordpress as a single site. How do I fix it... Can I remove wp_manageedit-postcolumnshidden option without harm for Site?

#5 @iseulde
4 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

This ticket has not seen any activity in over *two* years, so I'm closing it as "wontfix".

The ticket may lack decisiveness, may have become irrelevant, or may not have gathered enough interest.

If you think this ticket does deserve some attention again, feel free to reopen.

For bugs, it would be great if you could provide updated steps to reproduce against the latest version of WordPress (5.0.2 at the time of writing). Remember images or a video can be superior to explain a problem. At the very least, quickly test again to make sure the bug still exists.

If it’s an enhancement or feature, some extra motivation may help.

Thank you for your contributions to WordPress! <3

#6 @JeffPaul
7 weeks ago

  • Keywords bulk-reopened added
  • Milestone set to Awaiting Review
  • Resolution wontfix deleted
  • Status changed from closed to reopened

A decision was made to reopen tickets that were closed in the bulk edit that this ticket was affected by. This ticket is being placed back into the Awaiting Review milestone so it can be individually evaluated and verified to determine if it is still relevant/valid or reproducible.

Note: See TracTickets for help on using tickets.