<tian2992>
ocdtrekkie, im a bit worried of getting outbound connections on a very old wordpress
<ocdtrekkie>
tian2992: So there are a couple key things about the design of this. First: Our WordPress package publishes static content only, so there's no way for a visitor of the published site to trigger any dynamic behavior or outbound network activity.
<tian2992>
OH OK OK
<tian2992>
even though fine grained support to API endpoint woudl be sick
<tian2992>
like getting content support e.g.
<ocdtrekkie>
Second: When you use that functionality inside Sandstorm, any access to any outside server requires explicit approval from the user per domain. So like by default, WordPress likes to talk to api.wordpress.org and if you allow that, the platform enforces that's the only endpoint WordPress reaches.
<ocdtrekkie>
I would love to do some crazy stuff like using client-side code that hits the API endpoint to re-enable commenting in a safe way or something, but yeah, nothing in my experimental package is so bold.
<ocdtrekkie>
This just allows the grain owner/people you share editing access with the ability to import media, update plugins, etc.
<ocdtrekkie>
But what I needed this for also I really need to be in like the 5.x versions somewhere at least, so I need to start working on ratcheting up the package to newer WordPress versions soon.
<tian2992>
do you have a repo or smth?
<tian2992>
also have you considered the diff approach
<ocdtrekkie>
To some degree it is already building a diff off of the wordpress package but there are some modifications in the wordpress too which would need to be identified and re-done a different way.
garrison has quit [Ping timeout: 260 seconds]
garrison has joined #sandstorm
xet7 has quit [Ping timeout: 260 seconds]
xet7 has joined #sandstorm
<isd>
identifying the commits that were sandstorm specific to put in the patches directory is probably as simple as git log HEAD ^upstream/master (from the checked out wordpress, assuming you've got 'upstream' as a remote to the original); this is more or less what I did when updating mediawiki.
<isd>
Not urgent, but it made it a lot easier than if the packaging goop & upstream patches were in the same repo already
<Ryuno-KiAndrJaen>
FWIW Forgejo has a „soft-fork-tools“ repo aiming at providing bash scripts for handling rebasing strategies
<Ryuno-KiAndrJaen>
Documentation is… lacking in my opinion. But might be helpful nonetheless if you follow a similar strategy.
<Ryuno-KiAndrJaen>
Code is on Codeberg
<xet7>
Hmm. Which one is better, Forgejo or Fossil SCM ?
<isd>
I'm sure the correct answer here is "it depends"
<Ryuno-KiAndrJaen>
I haven't worked with Fossil yet but Forgejo is facing internal and financial struggles at the moment in my opinion.
<Ryuno-KiAndrJaen>
I can talk more in detail if you like (I'm member there).
<Ryuno-KiAndrJaen>
Feel free to DM me
<ocdtrekkie>
<isd> "identifying the commits that..." <- So in this case, the repo is not a fork of upstream, updates are single commits overwriting changes with a newer WordPress, likely handling breaking changes inside said commit.
<ocdtrekkie>
It's ugly.
<isd>
Ew.
<Ryuno-KiAndrJaen>
Yikes
<Ryuno-KiAndrJaen>
So basically a set of patch files?
kentonv has quit [Quit: Leaving]
kentonv has joined #sandstorm
<tian2992>
yes but that is why it would not be just overwriting the changes
<tian2992>
diffing with the current version of WP that was available when it was created
<ocdtrekkie>
It's absolutely a doable thing we should do at some point. It's just a slog of work that needs to be handled.
<ocdtrekkie>
So like the mkdocs update PR we got appears to produce reasonable output. I may just like... yolo it and fix from there. I suspect the reason we held back was that old plugin to generate that diagram.