Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#11356 closed enhancement (wontfix)

Folder for third-party libraries

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


I am working on a theme framework for Wordpress which has the ability to load in what I call "theme extensions", they act allot like Wordpress plug-ins and can be easily managed through a custom theme options interface.

My first theme extension is designed to create a seamless connection between Flash and Wordpress using the Zend Framework, in particular the ZendAmf package. Currently I have a "vendors" folder inside my theme framework which houses any third-party libraries used by the framework itself and also theme extensions.

It makes more sense to have these third-party libraries stored in a recognizable location where all plug-ins and themes can access them. For example.


I realize I could just create this folder myself, however I think it would be a great idea to included a default folder with the purpose of storing third-party libraries and maybe you could set an include_path to this folder by default as well?


Change History (6)

#1 @ontic
6 years ago

  • Component changed from Plugins to General
  • Keywords zend added
  • Milestone changed from Future Release to 2.9
  • Owner westi deleted
  • Version 2.9 deleted

#2 @nacin
6 years ago

  • Milestone changed from 2.9 to Future Release

2.9 is feature-frozen. Moving back to future.

This doesn't seem like something for core.

#3 @greenshady
6 years ago

Why not just load these third-party libraries as plugins?

#4 @ontic
6 years ago

@nacin: Can you explain why you think this shouldn't be part of the core? Just curious.

@greenshady: You bring up a good point, I can honestly say that packaging third-party libraries as plugins was not something I considered. Maybe I have tunnel vision and can't see the bigger picture? How do you envision this would work? In particular the distribution of such a plugin.

Wouldn't it be adding an unnecessary dependency? You then have a plugin which depends upon another plugin being enabled. When really the plugin just needs to know if a class or file exists and act accordingly (e.g. include the file, maybe check the version, or throw an error).

Would the plugin author then be responsible for updating the plugin every time something changes within the library? The likes of Zend push out new releases all the time.

#5 @nacin
6 years ago

  • Keywords close added

Replying to ontic:

@nacin: Can you explain why you think this shouldn't be part of the core? Just curious.

For starters, for exactly what greenshady said. No need to reinvent the wheel. The first thing that came to mind is that this isn't just plugin material to implement it, but they're plugins themselves.

You can also create this directory on your own, or use the wp-content directory, etc. You can probably build your own plugin to manage and keep updated vendors folders/files, even. Check out the filesystem and HTTP APIs.

Using (function|file|class)_exists to ensure dependencies across plugins already happens, so nothing new there. You could also check which plugins are installed and what version they are at.

Speaking of reinventing the wheel, it would make sense for your theme extensions to be loaded as plugins.

#6 @sivel
6 years ago

  • Keywords third-party zend close removed
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

No movement in 2 months. Closing as wontfix.

Note: See TracTickets for help on using tickets.