Make WordPress Core

Opened 17 years ago

Closed 16 years ago

#4899 closed enhancement (wontfix)

Create wp-includes/class folder to store WordPress classes Proposal

Reported by: darkdragon's profile darkdragon Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.3
Component: General Keywords: classes proposal
Focuses: Cc:

Description

Classes should be organized in its own folder for several reasons.

  1. Allows for Classes to be Unit Tested easily. Some classes are within files that contain presentation, which doesn't easily allow for unit testing the class.
  2. Single location to find classes, moves classes that are within other files into a location where developers and plugin authors can find them. Intuitive locations.
  3. Submitting Patches for classes should allow for better versioning.
  4. Possible optimization by only including the classes that are needed. (Think Administration or installer)

I propose that the PEAR class organization should be used for WordPress classes. The external libraries should also be located in wp-includes/class, but not broken up into the PEAR convention.

The PEAR convention is to organize the files in folders between the dashes and use dashes as '/'.

Backwards Compat

The old include files will be retained and just include the classes that existed in the file previously.

Examples

WP_Cache: wp-includes/class/WP/Cache.php

WP_Ajax_Response: wp-includes/class/WP/Ajax/Response.php

Attachments (3)

class.xmlrpc.patch (57.3 KB) - added by darkdragon 17 years ago.
Removes WP_XMLRPC_Server class from xmlrpc.php. Based on [6021]
class.xmlrpc-wp-xmlrpc-server.patch (146.5 KB) - added by darkdragon 17 years ago.
Addes both the wp-includes/xmlrpc.php functions, class folder (might have to manually add it, if patch doesn't), and WP_XmlRpc_Server class. Based off [6021]
class.app.patch (127.0 KB) - added by darkdragon 17 years ago.
Remove AtomServer from wp-app.php. [6021]

Download all attachments as: .zip

Change History (12)

#1 follow-ups: @darkdragon
17 years ago

Oh yeah, class files shouldn't include optional ending PHP tag.

@darkdragon
17 years ago

Removes WP_XMLRPC_Server class from xmlrpc.php. Based on [6021]

@darkdragon
17 years ago

Addes both the wp-includes/xmlrpc.php functions, class folder (might have to manually add it, if patch doesn't), and WP_XmlRpc_Server class. Based off [6021]

#2 @darkdragon
17 years ago

class.xmlrpc.patch should be applied to the root and class.xmlrpc-wp-xmlrpc-server.patch should be applied to wp-includes folder.

@darkdragon
17 years ago

Remove AtomServer from wp-app.php. [6021]

#3 in reply to: ↑ 1 ; follow-up: @westi
17 years ago

Replying to darkdragon:

Oh yeah, class files shouldn't include optional ending PHP tag.

-1 I don't see any benefit in this and WordPress Coding Standards state Always use full PHP tags (<?php ... ?>).

I am not convinced with building a folder hierarchy when we only have a small number of class files.

I would prefer just adding wp-includes/classes and moving classes into there.

#4 in reply to: ↑ 1 ; follow-up: @Viper007Bond
17 years ago

Replying to darkdragon:

Oh yeah, class files shouldn't include optional ending PHP tag.

Bad practice IMO and a dirty hack, one that's not needed since these files shouldn't be edited by the user. It's somewhat understandable for a config file or whatnot, but it's pointless for files like this.

#5 in reply to: ↑ 3 @darkdragon
17 years ago

I would say they would be, in fact, edited by the user to provide patches. I gave four reasons for doing this, I don't think people will be providing patches for config files either. I would rather have reasoning for all four, if only for my education.

As this is a proposal, I will add the closing PHP tag and resubmit the patches.

While I am most likely violating "You're not going to need it" paradigm, I think future develop could and should move to classes. In that event, a convention should be settled on now.

#6 in reply to: ↑ 4 @darkdragon
17 years ago

Replying to Viper007Bond:

Replying to darkdragon:

Oh yeah, class files shouldn't include optional ending PHP tag.

Bad practice IMO and a dirty hack, one that's not needed since these files shouldn't be edited by the user. It's somewhat understandable for a config file or whatnot, but it's pointless for files like this.

The debate on whether or not the closing tag should or should not be used is not conclusive and is more a matter of preference. It is only a "dirty hack" if all included files don't have trailing spaces. In the event that any file does and the user tries to use header after including said file, problems might or might not occur. See #4901 patch for files that do (said patch does nothing however).

#7 @darkdragon
16 years ago

  • Milestone 2.4 deleted

#8 @foolswisdom
16 years ago

  • Milestone set to 2.5

I like every open ticket to have a milestone, or it should be closed ;-)

#9 @darkdragon
16 years ago

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

Sigh.

Oh well, no point having an ticket open wasting space. As with the moving of admin functionality to separate files, this really depends on the core devs.

Recent information has pointed to the decrease in performance, so, you know. If this happens, then yeah! If not, then oh well.

Note: See TracTickets for help on using tickets.