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 | 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.
- 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.
- 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.
- Submitting Patches for classes should allow for better versioning.
- 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)
Change History (12)
@
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
@
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.
#3
in reply to:
↑ 1
;
follow-up:
↓ 5
@
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:
↓ 6
@
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
@
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
@
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).
#8
@
16 years ago
- Milestone set to 2.5
I like every open ticket to have a milestone, or it should be closed ;-)
#9
@
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.
Oh yeah, class files shouldn't include optional ending PHP tag.