Make WordPress Core

Opened 17 years ago

Closed 17 years ago

Last modified 10 months ago

#5261 closed defect (bug) (worksforme)

Array issues in plugins.php

Reported by: aroundmyroom's profile aroundmyroom Owned by:
Milestone: Priority: high
Severity: normal Version: 2.3
Component: General Keywords: has-patch has-unit-tests
Focuses: Cc:

Description

version 2.1.3 is working without any problem, but with the release of version 2.2.2 there was introduced a bug called: ARRAY bug
at the support forums you can read this issue from other people as well
http://wordpress.org/support/topic/118367/page/2
the solution for 2.2.2. was given by user SEVENETH posting some code to be changed in the plugin.php

Trying to upgrade from 2.1.3 to 2.3 causes for me a lot of array issues inside the dashboard and options including the loss of all categories

During my testing for 2.3 and now 2.3.1 I see the same issue

if tracking my test weblog at http://www.aroudmyroom.com/test you also can see that there does exist an array category made by the system itself

The server is running
PHP Version 4.3.9
Apache/2.0.52 (CentOS

in the support forums it seems that the ticket for the array issue was too easily closed and too easily refered to an necessary update for PHP and/or ZEND

Attachments (2)

plugin.5261.fix.patch (523 bytes) - added by darkdragon 17 years ago.
Take one, will need testing.
plugin.5261.fix2.patch (439 bytes) - added by darkdragon 17 years ago.
Take two, will not need testing, solution provided by referenced forum thread.

Download all attachments as: .zip

Change History (15)

#1 @darkdragon
17 years ago

  • Summary changed from Array issues to Array issues in plugins.php

#2 @foolswisdom
17 years ago

  • Milestone changed from 2.3.1 to 2.3.2

@darkdragon
17 years ago

Take one, will need testing.

@darkdragon
17 years ago

Take two, will not need testing, solution provided by referenced forum thread.

#3 @darkdragon
17 years ago

  • Keywords has-patch added

#4 @darkdragon
17 years ago

Take 1: Needs testing. Basically, what it does is use the $r check to make sure that the element exists in the multi-dimensional array and if so, then remove it. What would need testing is to make sure that it does in fact do what it needs too.

Take 2: Merely overrides (hey, it was going to be deleted anyway) or sets the keys to exist before unset. It would be quicker to use this method as the branch will slow things down in take two.

Pick one.

#5 @darkdragon
17 years ago

Hmm, not quite, the assignment probably take as much time as the branching.

#6 in reply to: ↑ description @aroundmyroom
17 years ago

Version 2.3.1-RC1 is indeed removing the array issue everywhere
after applying the patch in the plugin.php

I will update my test wordpress with the latest version tonight and check again.

Replying to aroundmyroom:

version 2.1.3 is working without any problem, but with the release of version 2.2.2 there was introduced a bug called: ARRAY bug
at the support forums you can read this issue from other people as well
http://wordpress.org/support/topic/118367/page/2
the solution for 2.2.2. was given by user SEVENETH posting some code to be changed in the plugin.php

Trying to upgrade from 2.1.3 to 2.3 causes for me a lot of array issues inside the dashboard and options including the loss of all categories

During my testing for 2.3 and now 2.3.1 I see the same issue

if tracking my test weblog at http://www.aroudmyroom.com/test you also can see that there does exist an array category made by the system itself

The server is running
PHP Version 4.3.9
Apache/2.0.52 (CentOS

in the support forums it seems that the ticket for the array issue was too easily closed and too easily refered to an necessary update for PHP and/or ZEND

#7 @darkdragon
17 years ago

Which patch did you use? Mine or the one in the forum?

#8 @aroundmyroom
17 years ago

Darkdragon:

I used your patch and for 2.3.1RC1 it was working indeed, the forum fix I only used in 2.2.2

now just copied all 2.3.1 sources over the 2.1.3RC1 location & using same config: re-applied the patch onto the new plugin.php

But now the ARRAY is again appearing in the Pages (see http://www.aroundmyroom.com/test -> right side column
and in the admin menu you can see it clearly selecting ie. categories, for a new category everywhere we see 'ARRAY'

like: Presentation

Current Theme
Array Array by Array
Array

All of this theme’s files are located in Array.

or when selecting users: Authors & Users you do not see anything ..
at the profile
Yahoo IM:
ARRAY

Jabber / Google Talk:
ARRAY

So the patched worked for 2.1.3RC1 but for 2.1.3 a no go

in my plugin.php it is around line 104

$r = isset($GLOBALSwp_filter?[$tag][$priority][$function_to_remove]);

$GLOBALSwp_filter?[$tag][$priority][$function_to_remove] = array();

unset($GLOBALSwp_filter?[$tag][$priority][$function_to_remove]);

unset($GLOBALSmerged_filters?[$tag]);

}

this is not working in 2.3.1 but did in 2.3.1RC1

#9 @aroundmyroom
17 years ago

erratum:

" So the patched worked for 2.1.3RC1 but for 2.1.3 a no go "

must be

.... 2.3.1RC but for 2.3.1 a no go ..

#10 @aroundmyroom
17 years ago

  • Cc darkdragon added
  • Resolution set to worksforme
  • Status changed from new to closed

update:

after the failing 2.3.1 again I re-applied the forum patch:

$r = isset($GLOBALSwp_filter?[$tag][$priority][$function_to_remove]);

$wp_filter[$tag][$priority][serialize($function_to_remove)] = array();
unset( $wp_filter[$tag][$priority][serialize($function_to_remove)] );

unset($GLOBALSmerged_filters?[$tag]);

if( true === $r) {
unset($GLOBALSwp_filter?[$tag][$priority][$function_to_remove]);
unset($GLOBALSmerged_filters?[$tag]);

}

return $r;

}

and the array issue disappeared everywhere from main page as in dashboard options
users menu is working again, profile is ok etc..

#11 @Nazgul
17 years ago

  • Milestone 2.3.2 deleted

This ticket was mentioned in PR #5257 on WordPress/wordpress-develop by @Bernhard Reiter.


10 months ago
#12

  • Keywords has-unit-tests added

Per https://github.com/WordPress/wordpress-develop/pull/5247#discussion_r1331151853, I realized that sibling block insertion wasn't likely going to work the way I had planned. As a consequence, I had to come up with a new way to make it work.

Basically, we:

  • Change the signature of the existing callback such that:
    • the function arguments are now a _reference_ to the current block (so it can be modified inline, which is important e.g. for theme attribute insertion), the parent block, and the previous block (instead of the block index and chunk index)
    • the return value is now a string that will be prepended to the result of the inner block traversal and serialization.
  • Add a second callback argument to traverse_and_serialize_block, which is called _after_ the current inner block is traversed and serialized.
    • Its function arguments are a reference to the current block, the parent block, and the next block.

Its usage is demonstrated in #5261: The callback arguments are now sufficient to insert the serialized hooked blocks as strings, rather than via insert_inner_block, prepend_inner block, or append_inner_block.

Trac ticket: TBD

Note: See TracTickets for help on using tickets.