WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#34432 closed task (blessed) (fixed)

Customizer subclasses can be broken out and remain BC

Reported by: wonderboymusic Owned by:
Milestone: 4.4 Priority: normal
Severity: normal Version: 3.4
Component: Customize Keywords:
Focuses: Cc:

Description

The Customizer base class files can load their implementations at the bottom of the file via require_once(), instead of moving everything and then loading everything in a manifest.

The Customizer code can make sublime sense when you are looking at small implementations of the base classes by themselves, it is overwhelming to look at a multi-thousand-line file to debug a 100-line class.

I waited to think this through after #33413. Loading them like this should be a non-event, but will make the code infinitely more readable.

Change History (8)

#1 @wonderboymusic
5 years ago

In 35383:

Customize: move WP_Customize_Setting subclasses to wp-includes/customize, they load in the exact same place.

See #34432.

#2 @wonderboymusic
5 years ago

In 35385:

Customize: move WP_Customize_Section subclasses to wp-includes/customize, they load in the exact same place.

See #34432.

#3 @wonderboymusic
5 years ago

In 35386:

Customize: move WP_Customize_Panel subclass to wp-includes/customize, it loads in the exact same place.

See #34432.

#4 @wonderboymusic
5 years ago

In 35389:

Customize: move WP_Customize_Control subclasses to wp-includes/customize, they load in the exact same place.

See #34432.

#5 @wonderboymusic
5 years ago

  • Resolution set to fixed
  • Status changed from new to closed

This ticket was mentioned in Slack in #core by sergey. View the logs.


5 years ago

#7 @azaozz
5 years ago

I'm not sure this is a good idea. It adds more server i/o to load 27 files, so it is a bit worse for the users.

I suspect the idea of "one class per file" comes from languages that are compiled (C, C++, etc.) where the code is combined before execution. It doesn't make much sense in languages that use interpreter like PHP where each file is "loaded" on every run. Especially when many of the files have only 2-3 lines of code in them.

From "coding" point of view, IMHO having many files with just few lines of code makes it harder to edit anything in them as it requires you to have 15-20 files opened at the same time and switching between them is disorienting after a while. Grouping similar (small/short) classes in one file will probably be better and makes changing them easier.

I've been having some doubts about #33413 too. The reason for splitting there was this part of PSR-1:

A file SHOULD declare new symbols (classes, functions, constants, etc.) and cause no other side effects, or it SHOULD execute logic with side effects, but SHOULD NOT do both.

As far as I understand it, that means there shouldn't be "loose" code and classes/functions in the same file, example:

echo '123';

function my_func() {
  echo '456';
}

I agree, this sounds good. Most of the WP code complies with it except few "template" files in wp-admin. However this has nothing to do with having to split classes into separate files. Agree it "looks a bit cleaner" right now, just worried about reduced performance if we continue to add more "super short" files.

Last edited 5 years ago by azaozz (previous) (diff)

This ticket was mentioned in Slack in #core by westonruter. View the logs.


4 years ago

Note: See TracTickets for help on using tickets.