Widget classes when custom widget class is namespaced

[rogerlos]

Widgets output from a namespaced class have a class added to the before_widget argument in a way which is potentially confusing and messy to work with.

The before_widget value within the arguments array sent to the widget() method within WP_Widget looks something like this when using a namespaced custom widget class:

<aside class="widget \myplugin\My_Widget" id="mywidgetname_widget-1">'

Given my understanding of WP's "normal" escaping of attributes, I would have expected myplugin-My_Widget, mywidgetname myplugin-My_Widget or maybe mypluginMy_Widget.

I believe that technically the two escape characters make the WP output the equivalent to the latter, but it's a bit messy and potentially confusing to folks looking to style the output, or find the aside using JS.

[welcher]

@rogerlos thanks for the ticket! Can you share the code you are using to register the widget? My local tests are not getting the same results.

[Mte90]

I can confirm the issue.
This happens when you don't define the id_base that is automatically generated.

<?php
// https://developer.wordpress.org/reference/classes/wp_widget/
// line 163
 $this->id_base         = empty( $id_base ) ? preg_replace( '/(wp_)?widget_/', '', strtolower( get_class( $this ) ) ) : strtolower( $id_base );

So it use the class to generate it but if it is a namespace generated namespace\sub\sub\class doesn't do anything creating this issues.

[Mte90]

Whan happens when the widget is a class initialized by a namespace without id_base defined

As https://core.trac.wordpress.org/ticket/44098 this happens when the widget is initialized without defining the id_base that is auto generated. The problem is that doesn't handle namespaces so this can create warning by php because the preg_match include a string with a backslash \.

Trac ticket:

[Mte90]

I did a first patch version, I added a test but require some review.

[prbot]

​Mte90 commented on ​PR #435:

This should fix the linting but for the test failing I don't know how I can mock a fake namespace and class.

[prbot]

​hmfs commented on ​PR #435:

Hello @Mte90 ,

I am a new (hopeful) contributor. I saw this Trac ticket posted in the WordPress core slack room.

I was able to get the test to work by adding a namespaced widget. It seems cleaner to do this in a separate file than to try to add it to the original widget test file. I also had to adjust the logic in WP_Widget because end will fail the test when its argument is not a variable.

The code is available ​here.

Please let me know if you have questions.

[prbot]

​Mte90 commented on ​PR #435:

Hi @hmfs I merged your patch in this pull request.
Let's see if it is good now :-)

[prbot]

​Mte90 commented on ​PR #435:

@hmfs now the unit tests fails Fatal error: Class 'Namespace\Sub\Sub\Class' not found in /var/www/src/wp-includes/class-wp-widget-factory.php on line 61

[prbot]

​hmfs commented on ​PR #435:

Hi @Mte90 ,

Thanks for the notice.

The test in tests/phpunit/tests/widgets.php should be removed because it was migrated into the first test in tests/phpunit/tests/widgets-namespaced.php due to the complexity of adding multiple namespaces per file.

It also looks like the coding standards are complaining about the structure of widgets-namespaced.php.

Both issues are fixed in this new PR to this branch: ​https://github.com/Mte90/wordpress-develop/pull/4

[prbot]

​Mte90 commented on ​PR #435:

Perfect :-D

[SergeyBiryukov]

Thanks for the PR!

Just noting that this also has backward compatibility concerns, as the id_base value is not only used for the widget's id and class attributes, but also for the option name which stores the widget settings (unless the widget specifies a custom option_name value).

If we only take the last part of the widget class name as id_base, it could conflict with a widget of the same name from another namespace, or a non-namespaced widget of the same name.

So it seems better to take the whole widget class name (including the namespace) and convert backslashes to hyphens, that way we should get a unique value.

That might still cause some previously saved namespaced widgets to disappear or lose their settings due to the option name change, but let's try this during the beta phase and see if we have any reports of that.

If we do get any reports, we might want to consider only doing this for the classname value and not for id_base.

[SergeyBiryukov]

In 50953:

Widgets: Make sure WP_Widget constructor creates a correct id_base value for a namespaced widget class.

The id_base value is used for the widget's id and class attributes and also for the option name which stores the widget settings (unless the widget specifies a custom option_name value).

With this change, any backslashes in the id_base for a namespaced widget class are converted to hyphens, making it easier to style the output or target the widget with JavaScript.

This also avoids a preg_match(): Compilation failed PHP warning from next_widget_id_number() on the Widgets screen, previously caused by unescaped backslashes.

Props Mte90, hermpheus, rogerlos, welcher, SergeyBiryukov.
Fixes #44098.

[SergeyBiryukov]

Replying to SergeyBiryukov:

That might still cause some previously saved namespaced widgets to disappear or lose their settings due to the option name change, but let's try this during the beta phase and see if we have any reports of that.

If we do get any reports, we might want to consider only doing this for the classname value and not for id_base.

On second thought, if the only concerns here are the class name and the PHP warning, it seems like a safer approach to just address that, instead of changing id_base. Since the handbook has an ​example with a namespace, it might be too common a pattern in the wild to cause any unnecessary breakage.

Let's also switch to underscores to avoid a mix of underscores and hyphens. See 44098.diff​.

[Mte90]

Seems a better solution that patch.

[SergeyBiryukov]

In 50961:

Widgets: Make sure WP_Widget constructor creates a correct classname value for a namespaced widget class.

This reverts the changes to id_base from [50953] due to backward compatibility concerns, and instead focuses on the id and class attributes specifically.

With this change, any backslashes in the id or class attributes for a namespaced widget class are converted to underscores, making it easier to style the output or target the widget with JavaScript.

Follow-up to [50953].

Fixes #44098.

[prbot]

​Mte90 commented on ​PR #435:

Ticket resolved

[hellofromTonya]

#16773 was marked as a duplicate.