WordPress.org

Make WordPress Core

Opened 18 months ago

Closed 8 months ago

Last modified 8 months ago

#22303 closed enhancement (maybelater)

Please parse a "vendor" file

Reported by: remicollet Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:

Description

Hi,

I'm working on improving Wordpress packaging in fedora.

One of our need is to allow the use of system libraries instead of bundled copy (forbidden by Guidelines).

I would like to propose, as various projects already, to include a "vendor" file.

Goals:

  • without this file: no change
  • with this file: use constant from it
  • allow to define patch for each library (rather than a global WPINC)

Note: this is not the same as wp-settings, which are user configurable settings, while "vendor" are system configuration (not to be altered by users)

Work proposal.

(probably) in default-constants.php

if (file_exists('vendor.php')) include_once('vendor.php');

For PHPMailer (for exemple)

if (!defined('WP_PHPMAILER_INC')) define('WP_PHPMAILER_INC', ABSPATH . WPINC);

And of course,
require_once WP_PHPMAILER_INC . '/class-smtp.php';

Using this, we could package wordpress in a simpler way, without altering provided sources, just adding this vendor file.

For example, see what have be done in GLPI
https://forge.indepnet.net/projects/glpi/wiki/GlpiPackaging

If you accept this feature, I will work on it and submit the patches (probably various, one per library, as I will progress on this work).

Change History (17)

comment:1 dd3218 months ago

  • Keywords reporter-feedback added

For those people who do not use Linux package managers for web packages, can you please outline the reasons why distro's do this? (Forbidden by guidelines is NOT our problem, nor a valid reason IMHO, but explaining the reasoning behind those may be)

We have to ship modified versions of external php libraries in some cases, or beta releases, and even require a certain version within a release (either an older, or newer version), so in general I don't think this is something we can, or should, support - but I'm open to being swayed myself.

comment:2 remicollet18 months ago

  • Keywords reporter-feedback removed

can you please outline the reasons why distro's do this?

Main reason why distro don't want bundled libraries:

  • security : use system libraries allow to handle a single security update, when needed, rather than having to update each package which bundle a library
  • licensing issues : are you absolutely sure that all bundled libraries are released under license compatible with one of WordPress ?

More information : https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

We have to ship modified versions of external php libraries in some cases

I think you will probably hate a WordPress fork. So simply imagine what the authors of the libraries you are shipping feels ? So, IMHO, this change should be reported to each upstream project.

and even require a certain version within a release (either an older, or newer version)

This is the packager job to ensure that this requirement are meet (help/documentation from upstream is of course welcome)

so in general I don't think this is something we can, or should, support

Of course, the package have to be supported by the distro package maintainer.

Don't forget that having a package included in a linux distribution could give more visibility to your project (even if WordPress probably don't need this) and make WordPress's users life really simpler (single point of installation / update).

On another side, don't forget than most linux distribution have similar Guidelines. For fedora, one of our rules if "upstream first", so I really prefer to discuss such feature with you (the project) rather than patching the sources to respect our Guidelines.

comment:3 toscho18 months ago

  • Cc info@… added

comment:4 mcepl18 months ago

  • Cc mcepl added

comment:5 dd3218 months ago

  • Keywords dev-feedback added

licensing issues : are you absolutely sure that all bundled libraries are released under license compatible with one of WordPress ?

Yes. Also, we can't just not ship a library we use, as other than some jQuery UI components, we rely upon them being available - and that isn't changing.

We have to ship modified versions of external php libraries in some cases

I think you will probably hate a WordPress fork. So simply imagine what the authors of the libraries you are shipping feels ? So, IMHO, this change should be reported to each upstream project.

I think I phrased it wrong, We do package certain older libraries, or stable releases of libraries with patches applied (that have been passed up stream), We can't always wait for a new stable release of external libraries, although it's less common that we have to do it. (Although, really, a packaged version of WordPress in a distro is generally a fork due the modifications made anyway)

Don't forget that having a package included in a linux distribution could give more visibility to your project (even if WordPress probably don't need this) and make WordPress's users life really simpler (single point of installation / update).

In my experience, users who use distro-distributed editions of WordPress have more support issues, as the builtin upgrading and instructions are not available to them, don't work, or plugins simply don't work with it (as it's a different configuration than most).
As they're using a web application, they're not also likely to be using the command line, or a GUI, for updates as often as they would be using the WordPress admin.

I'm personally against distro builds of most web software which is user installable, but I'm still open to doing a certain level of work to allow all users of WordPress to use it as they wish (and I'm not the last word on this ticket either).
I'm willing to suggest this is a wontfix myself, but leave it up to other developers for their views.

comment:6 follow-up: MikeSchinkel18 months ago

  • Cc mike@… added

This seems like a perfectly reasonable request and approach, although the discussion of bundling confused me and I wonder if it's mention was a distraction from the goal of the ticket?

Unless I misunderstand the request this simply allows Fedora or any other distro to take a standard WordPress version download and add distro-specific support and/or optimizations in a separate file that the distro maintains. Using his example I can see better SMTP integration as being very helpful; I know having to deal with that on a plugin level can be a real pain for non-technical end-user bloggers. So this seems like a much better approach than forcing the distro to create a fork which means they then have to intercept the WordPress core update process to reapply their fork which I can see as very problematic.

With his approach this vendor file can go in the /wp-content/ directory and updates simply won't affect it. I can see potential security concerns if the vendor file needs to be updated but would think a discussion of how to address those concerns would be more productive than having them fork and maintain a WordPress download.

Also, I think the proposal I made on #22251 would be helpful if this proposal gets any traction.

comment:7 follow-up: SergeyBiryukov18 months ago

if (file_exists('vendor.php')) include_once('vendor.php');

It's currently possible to create a must-use plugin (e.g. mu-plugins/fedora.php) that would be automatically included.

I guess what this ticket needs to proceed is a list of hooks or constants which don't currently exist and are required in your case.

comment:8 in reply to: ↑ 7 MikeSchinkel18 months ago

Replying to SergeyBiryukov:

if (file_exists('vendor.php')) include_once('vendor.php');

It's currently possible to create a must-use plugin (e.g. mu-plugins/fedora.php) that would be automatically included.

I guess what this ticket needs to proceed is a list of hooks or constants which don't currently exist and are required in your case.

Must-use plugins are probably not loaded early enough to be able to pre-define constants that they may need to define before they get defined by WordPress itself. There's a lot of code that gets executed between default-constants.php and when the 'muplugins_loaded' hook is fired.

comment:9 in reply to: ↑ 6 ; follow-up: scribu18 months ago

Replying to MikeSchinkel:

So this seems like a much better approach than forcing the distro to create a fork which means they then have to intercept the WordPress core update process to reapply their fork which I can see as very problematic.

Actually, to comply with their guidelines, they'd have to delete the bundled library, so they'd have to intercept the update process anyway, so that argument is moot.

comment:10 scribu18 months ago

And, like dd32, I would never recommend users install WordPress via a package manager, because they're almost always out of date by one or more major releases.

comment:11 scribu18 months ago

  • Keywords close added; dev-feedback removed

comment:12 in reply to: ↑ 9 MikeSchinkel18 months ago

Replying to scribu:

Actually, to comply with their guidelines, they'd have to delete the bundled library, so they'd have to intercept the update process anyway, so that argument is moot.

I honestly don't understand how the "bundled library" concern matters here either way; WordPress is not shipped as a library. What "bundled library" are we talking about here? I seriously don't get how this applies.

Replying to scribu:

And, like dd32, I would never recommend users install WordPress via a package manager, because they're almost always out of date by one or more major releases.

That's not the point. The options as per @remicollet's comments are 1.) WordPress support Fedora's inclusion of WordPress or 2.) Fedora forks WordPress and maintains the fork which may or may not have the quality of WordPress core.

So whether or not you recommend users install via a package manager is orthogonal to the discussion. And with the auto-notices for upgrades and one-click upgrades, installing an older version really becomes a moot point. And after the one-click upgrade the vendor.php file that supports the distro would remain.

What is relevant is "Can Fedora ship a non-forked version of WordPress?" To do that Fedora needs a only tiny bit of help from WordPress.

comment:13 follow-up: dd3218 months ago

  • Keywords dev-feedback added

Replying to MikeSchinkel:

I honestly don't understand how the "bundled library" concern matters here either way;

The concern is that WordPress includes external libraries such as SimplePie and PHPMailer, Fedora, amongst others, states that external libraries such as these are not permitted to be included within a Package, "WordPress" package in this instance.

The request is for a auto-loaded file which can define alternate filesystem paths to the packages which WordPress uses, removing control of the version of the library WordPress uses.

Fedora can ship a non-modified version of WordPress if they wish, they just choose not to. They would have to fork WordPress regardless to remove the External libraries from the package, and even then, we have the fact that we don't name external library files the same as some of the projects (ie. class-phpmailer.php) which would further complicate matters when it's a library split between multiple files (SimplePie for example)

2.) Fedora forks WordPress and maintains the fork which may or may not have the quality of WordPress core.

Any forked copy or distributed copy of WordPress which uses external libraries not controlled/included by us, may not have the same quality of WordPress core, may have other bugs, or may not work as intended - this is something we loose control of by handing control of the external libraries over to someone else.

A prime example of this is when a Plugin or Theme replaces jQuery with a different version and all hell breaks loose - this is exactly the same, except instead of a JS bug, it's a PHP or application bug - potentially not reproducible in a stock install and only reproducible on the exact same package setup as the reporter - I believe we've already seen at least one bug report which was caused by a debian modification (The answer was "Uninstall it, re-install it from the official source, & you won't have any more problems").

I'm not against making life easier for those maintaining WordPress packages, I'm just against making a change which potentially makes WordPress not as stable, or as user friendly as it already is.

comment:14 in reply to: ↑ 13 MikeSchinkel18 months ago

Replying to dd32:

The concern is that WordPress includes external libraries such as SimplePie and PHPMailer, Fedora, amongst others, states that external libraries such as these are not permitted to be included within a Package, "WordPress" package in this instance.

That makes sense now. Thanks for explaining.

I'm not against making life easier for those maintaining WordPress packages, I'm just against making a change which potentially makes WordPress not as stable, or as user friendly as it already is.

Understood, and agree on the principle. But if the result is they fork it and make it less stable, wouldn't in principle it be best to find some middle ground to minimize the impact?

With that I'll leave this ticket because I clearly missed the part you explained about the bundling so now realize I don't have enough experience with all the issues.

Last edited 18 months ago by MikeSchinkel (previous) (diff)

comment:15 toscho18 months ago

I wonder where the users of such a package will get help? The regular channels (wordpress.org and wordpress.stackexchange.com) can’t do much here – I think these guidelines are incomplete if they do not solve the support issue.

Plus … more constants? More global variables?
I would rather not ship WordPress with the OS, but offer an easy way to get the latest stable version from wordpress.org.

comment:16 c3mdigital8 months ago

  • Keywords close dev-feedback removed
  • Resolution set to maybelater
  • Status changed from new to closed

Consensus seems to be maybe later.

comment:17 SergeyBiryukov8 months ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.