I’m not sure if this has already been addressed, but I was thinking it would be cool if ClassicPress supported git-php (or something similar) so ClassicPress can “checkout” a plugin automatically from GitHub? That way plugins could (potentially) be easily rolled-back if necessary.
That’s a great suggestion @gellenburg. I made this into its own thread under petitions, so it can get proper feedback and consideration from the core team and the community.
1 Like
That library is not needed to accomplish this.
I see no value in having the library as part of a CMS.
It just seemed like an unnecessary step to require plugins be zip’d up when you could “checkout” the plugin directly from GitHub (even the release tags) and install the plugin via git. I wasn’t sure if PHP had native support for git operations. (Sorry I’m not a dev my strengths are on the admin and security side).
1 Like
GitHub already provides zip files, so there’s no “unnecessary step”.
It is certainly an advantage to transfer code in a compressed format, so I wouldn’t be trying to sidestep that.
I don’t see why anyone would want to put specific version control commands into a CMS when it isn’t even about the content or related to revisions of the content.
2 Likes
The plan is to include the ClassicPress Plugin Directory within the Plugins plugin search of a ClassicPress site.
With that planned, I don’t see the value in integrating with GitHub in this way.
I guess I was thinking more in line with only transferring the deltas when a plugin is changed/ updated rather than having to transfer the full archive.
Couldn’t the Plugin Directory just store metadata for a plugin’s source? Like the name, description, released tags, etc. That way you’re not having to reinvent the wheel so much?
1 Like
The directory does only store the meta data; the download link points to the GitHub release zip.
1 Like
Not to mention that if you rely on using git to install the plugin sources and not just ZIPs you could potentially detect when a plugin has been modified maliciously like if a site gets hacked or something.
It should be trivial then to allow the site owner to verify the integrity of all the plugins and themes installed on their site by comparing the locally installed source against the repo on GitHub.
Software assurance.
I mean, ZIPs should be there as a backup and for those instances where someone may wish to sideload a plugin from outside the plugin directory, but using git as the transport and install medium would offer so much more flexibility.
1 Like
I think @wadestriebel would be the best one to offer some insight on this issue, since he’s leading development of the directory and can comment on the current plans for GitHub > Directory > ClassicPress integration.
I like the idea of being able to just checkout the latest release instead of relying on zips. 2 sided coin with zips with the current implementation, you can technically upload anything in the zip (ie. I did this by accident with a python file in the Migration Plugin). Whereas checking out a tagged version doesn’t have this issue and the code you are checking out is easy to view and compare.
Not sure how much work is required on the core side, but definitely something I can see the pros of. Might be worth looking into this for v2?
To add, this might also make sense if we continue to explore composer integration into core. Being able to composer require packages instead of uploading zips, composer uses the tagged version of the source code.
3 Likes
You also force people to have git when before a simple zip would do.
Don’t these plugins have hashes? You don’t need git for that.
Really, it doesn’t offer much of anything but more complexity and another software dependency.
We are doing this anyways with the git requirement to be listed on the directory?
No, the git software is not required to be on your server to use a zip file from GitHub. The proposal is for using a PHP library in core that has a dependency on git. This would make CP core larger for no good value, because we are not limiting plugins to be from the CP directory or GitHub.
Joy is right. git-php library requires Git client to be installed on the server. However, the petition isn’t limited to git-php:
So I think we can explore the concept of this petition and see if there is a way to do this without bloating the code or needing Git client. Maybe handling the Git process on the directory side and pushing only what’s needed to the ClassicPress sites would be a way to reduce code necessary in the core.
For example, if the directory maintains records of file changes between versions of plugins/themes and CP requests an updated version during the upgrade process, the directory would send new/edited files, and a list of files to delete. And there could be an option to force reinstall plugin, which would use the full zip file. And of course the regular zip file installation would still work.
This borrows some concepts from backup plugins that do incremental backups and restores.
What is the point of that, and how would it be better than deleting the folder and extracting the new zip? Trying to micromanage your software is crazy. The CP directory is a directory because we didn’t want a repository. Keep it simple!
2 Likes
I’ll defer to Wade’s answer:
1 Like
I will be honest, I am not sure what you are arguing against? The requirement of having git on your server? I haven’t spun up a new server that hasn’t had git pre-installed, but sure we could make it a core plugin so people can choose to enable it. I still think this petition overall is a good idea even if it is just pointing us in a good direction (ie. composer).
I think a compromise to this would be leveraging composer in a more robust fashion. This is how most modern frameworks now handle plugins/packages so clearly there is a reason for that.
1 Like
I’m against complicating core code for no benefit.
I’ve never had it on any of mine, especially not local ones…
I don’t think it’s pointing there, and I don’t agree that composer is even a good idea. Plugins and themes should be self-contained because you don’t know what the environment will be like.
1 Like