New Package Administration Interface

[left fjord]

Threaded for discussion.

[deep bronze]

The new layout is longer... it scrolls.
I'm not complaining, it looks better, it just made me realize how many things I've published. 😩

[neat dragon]

Please please do the API at latest on the day of the retirement

Or push the retirement until the automated API is live

[dense dome]

Suggestion: Add an explicit indication (on the /me/packages page, or on the individual page) that a package has been archived.

It might also be nice to see the supported foundry versions of the latest package release on /me/packages, for easy "what do I need to get to?" scanning

[neat dragon]

With 25+ premium packages that have all building steps automtated, it really really hard to manually update them on Foundry website and not make an error (wrong version or such)

[summer vault]

New Package Administration Interface

[hushed bloom]

looks alright for a peasant like me with 2 listed modules (and 2 unlisted). i dont expect isisues for my minimal use

[left fjord]

This is an unrelated suggestion, but a good one. I'll get a ticket opened on that as i don't think it would be prohibitively difficult to do.

[minor prairie]

The new layout does not let me access packages I have developed for someone else despite being part of said content provider. With the old "Admin" layout I could edit them.

[dense dome]

Fair - I thought /me/packages was new 😛

[winged birch]

I don't think it is

[errant anvil]

Its newer than admin!

But been here for a while

[winged birch]

Given that /admin is part of the Django framework itself, and therefore is as old as the site itself, everything else is newer than that, lol

[undone cargo]

You can access those packages via the content provider page: https://foundryvtt.com/creators/{content_provider_id}/edit/

[minor prairie]

No, I can't

[weak kelp]

me neither

[minor prairie]

It tells me I don't have permission

[weak kelp]

missing all the content providers packages and cant access

[languid sail]

I'll add that to my bug list then, I thought we had accounted for that in testing but there's likely a small piece I missed

[errant anvil]

As a note, you explicitly called out fvtt-autopublish package as becoming deprecated. Is foundry-publish also affected?

[weak kelp]

and I would like to have a search box, some 50ish modules and some more with the content provider then

[languid sail]

Almost certaintly

[neat dragon]

Most likely it is

[errant anvil]

😩

[languid sail]

Anything that points at the admin site

[neat dragon]

Which is sad cause it's only think that makes my releases... certain (I trust my automation more than my faulty brain and copy paste skills)

[errant anvil]

yeah

And yeah I use it for every package as well

[warped pivot]

The package tags seem module-oriented to me. I think we're missing a tag to indicate the package is a 'system'.

[winged birch]

That's determined back when you submit it

[minor prairie]

Honestly, I'd like it if content provider packages showed up on my username's package listing or the "Content Provider" tab gave links to the content provider(s)'s package list.

[left fjord]

As we state in the FAQ - we are exploring options for providing an actual API for package management, so i'll ask people to contain any panic about how this will affect any third party (not-recommended) automation solutions til a future discussion can be had about that. 🙂

[errant anvil]

Is there going to be an official-

welp

😅

[neat dragon]

It's not panic, its more desperate plea for the automation.

[vital depot]

On my individual packages, I'm not seeing an "Edit" option

[winged birch]

Are you logged in?

[warped pivot]

Alright but still, the form looks very oriented towards modules and is a bit confusing for systems.

[pallid shuttle]

Clearly there is a desire for an API given there are 2 packages already to automate the process. Which I guarantee will be updated to the new system.

[neat dragon]

Give me API key, and one endpoint to update package version and I will be overjoyed

[vital depot]

Yes. The /me/ page works fine

[languid sail]

ah, so like on /packages/<package>?

[cursive jasper]

Yes, same issue

[vital depot]

Yes

[languid sail]

that'll be fixed in a future update

[weak kelp]

the faq needs to have a heading DONT PANIC in red letters

[languid sail]

apologies

[summer vault]

Even if it was there, people will still panic.

[vital depot]

Could you edit the announcement post that that's a TODO?

[native lynx]

Yep, on it

[left fjord]

yeah, well.... people asked for an API to manage packages...and we told them it wasn't something we could devote development resources to....so they made unsupported tools to automate the admin page...and then other people became reliant on those packages despite them using unsupported approaches.

Basically it's the age-old cycle of community development XD XD XD

Please trust that we're taking the request for an API seriously and evaluating our options for what we feel comfortable providing.

[pallid shuttle]

Well if ya don't provide it I can guarantee people will use unofficial means to work around the defficency 😄

[vital depot]

As a small-module dev the /me/packages page has worked mostly fine, but I've also not yet had to go through several version updates

[pallid shuttle]

Just pushes the maintenance to the community 😄

[warped pivot]

latest version appearing at the top rather than bottom is a nice touch 👍

[neat dragon]

I prefer official APIs than you very much; most of the tools require giving your credentials and you can imagine it can be not fun

API with an API key is 1000x better

[pallid shuttle]

Oh I 100% agree. Just saying that without an official API developers will work around it.

[errant anvil]

Definitely, but in an absence of that, who's going to judge?

[vital depot]

Does this also mean we'll get the "Last Updated" counter fixed? Mine is still based on the last system update

[winged birch]

Which happens. But unofficial stuff getting depreciated due to changes happens too (as is happening here); that's the risk of unsupported stuff

[neat dragon]

I am saying we should just not tell Foundry staff we will work around it; let's not be like Bethesda where we have to fix and workaround stuff.

[vital depot]

(on desktop you can right click a thread to join/leave it)

[median python]

(Not on mobile 🙂 )

[polar vault]

Last I checked, if you make a small edit to the page text, that also resets the timer.

[languid sail]

oh good catch, @vital depot just adding a version doesn't do it but I can make it so

[left fjord]

Yeah, this. We very much prefer to keep open dialogues with the dev community. We'd rather work with you all than just have the devs find workarounds for issues they're facing.

[errant anvil]

Yes on mobile
https://cdn.discordapp.com/attachments/786153964999016468/1169356709861523567/image.png?ex=65551b4d&is=6542a64d&hm=c9c228c37a67fda1284c2a1271cad72a8d935627d715e1a7a2849ad7338077a9&

[pallid shuttle]

Which is why we're asking for an official API (and have been for a long time). Given community devs are the lifeblood of Foundry content you'd hope Foundry actually listened to requests to make our lives easier

[vital depot]

that would be much appreciated; to me the Last Updated bit should only be tied to module versions

[native lynx]

There are many improvements Foundry wants to do (and is actively doing!). The community helps to fill many of those gaps which is awesome.

This package management change has inadvertently boosted the priority of official automated releases, which I think will provide a nice net benefit to the dev community in the end

[vital depot]

If a module hasn't been updated since a system has been updated, the dates on the pages should let me know that

[languid sail]

This would be a much larger change, but can be done; I'll gauge the team's feelings on it and worst case it'll be tied to package updates + version updates

[vital depot]

Here's a simple example; on the SWADE system we've done a release every ~2 months or so this year, which often include a handful of breaking changes (e.g. we added a data model and that uncovered a ton of bad data in older compendium packs). It would be helpful to be able to see the package page and see "Hey, this package hasn't been updated since the system updated and there were breaking changes"

[languid sail]

Totally, will pass this along

[hushed lintel]

My packages are showing on my page, but I also have access to Evil Hat packages on the old manager, which I need to administer. Will they get added to the new interface package manager?

Also, if I'm going to have to work with this page regularly, I beg you for a light mode. The colour scheme of the package manager does not play well with my astigmatism

[languid sail]

this was a miss on my part that I've already noted, but let me send you a DM for a workaround

[winged birch]

I've found that some browser CSS rules can help a lot with those uncomfortable colors. I've had that set up on my browser for a while now

[neat dragon]

Also, at least for me you can treat API as accessibility improvement; with my light ADHD I really have troubles keeping up when updating a lot of packages - numbers; urls and such, I cannot tell you how many times I did bork the numbering before I employed automation for the releases

[left fjord]

lemme reiterate: we're already evaluating what we can do to provide an API, you don't have to convince us further. 🙂

[languid sail]

in fact instead of a DM:

• If you can access content provider packages to edit on the admin page but not through /me/packages, we're working on a fix.
• Workaround: navigate to the creator's page (i.e. https://foundryvtt.com/creators/evilhat/), click on a package (i.e. https://foundryvtt.com/packages/the-secrets-of-cats) and stick a /edit at the end

[neat dragon]

I am just helpin you prioritize it ;D

[hushed lintel]

I believe Anathema was working on a light mode a while back. 🙂

[hushed lintel]

Apparently I don't have permissions.

[native lynx]

Mission accomplished sir lol

[hushed lintel]

Oh wait, that might be 'cause I didn't click on a specific module first

[languid sail]

oh yes, you can only access the creators page with specific roles on the creator

that's part of the fix I'm going to be putting out, but I digress

[hushed lintel]

It was, that works. Fortunately they only need editing infrequently so by the time I'm next due to make a change it will probably be rolled out already

[left fjord]

I'll see what i can do- i was working on it but it never got finished.

Perhaps i can hand the unfinished work off to some actual devs to do something with

[languid sail]

@vital depot it is possible that the new add version form on the package edit page will solve your problem, actually; I believe if you add a version it updates the counter

[vital depot]

OK so when I bump my version from 1.0.2 to 1.0.3 it should be fixed? I'll report back when I do that

[stuck wigeon]

I'll provide another voice in favor of an API, but not as a stopgap

[worn mauve]

Is it possible for you guys to fix images not being centered by Align > Center?

[stuck wigeon]

I think rolling a auth'd package management API into your webapp by actually using the API as the way your frontend talks to your backend, will serve us all

ratelimit the snot out of us, of course. limit to 3 req per minute if it helps with swallowing the pill

that is, in case there's a fear of hundreds of requests

[left fjord]

sorry, to be clear about the API thing- we're evaluating internally but not looking for feedback on that specific issue at this time. Mostly we're looking for feedback about the new edit page.

[left fjord]

not really related to this discussion so please open a bug report in #1045406090285826158

[echo crown]

Yes, foundry-publish is affected by this. However, I’ll update it to work with the new workflow (I don’t see why that would not be possible). If (eventually) an API is available to do this stuff, I’ll update it to use the API. So it should continue to work seamlessly.

fvtt-autopublish could also be adjusted to work with the new workflow, btw.

[delicate trout]

The new package manager is slower to add a new entry. Previously it was possible to just tab into the old field, ctrl-c copy the data, then ctrl-v paste into the new field.
Now we have to scroll down to where the old versions are displayed, use popup menu to select the text, then scroll back up and copy into the final field - and repeat the window scrolling for each field.

Having the entire entry editable on a single line is much quicker and easier than a large vertical form of fields,

[left fjord]

i don't have much of a response to that other than to say I think it's valid feedback, but i did wanna thank you for moving over here to discuss it. 🙂

[delicate trout]

Putting all the fields in one line would make it easier to manage copying fields from an existing entry up to the new entry. (Columns lining up makes copying less likely to copy into the wrong field).
The large explanations of each field on the left only seem necessary for new users, and could easily be reduced to mostly tooltips.

[fossil panther]

The list of systems in "Required Game Systems" in the Django admin panel is nicely sorted, while the one in the new interface is not, making it incredibly difficult to find a specific system

It would be great if there was a clearer way to get to list of modules for a specific content provider, right now if you have the "Editor" role then you will see the "Edit" link on the content providers page of your profile, but if you are just a "Developer" then that doesn't appear, though you can still manually enter the URL to get to the edit page and find the list of packages

[worn mauve]

Idk if someone already noticed it, but there is no way to just update the version number without creating a new version on the new package interface, previously it was possible to just change the number on the admin page and it would be a new version.

[undone cargo]

I think this change is partially by design, but will discuss with the team

[steady cosmos]

I just encountered this. I only maintain the latest version on most of my packages (except for two, where I also have a v10-compatible version). Can we hear the reasoning behind this design decision?

[winged birch]

I feel like "make a new version; at which point you can delete the old version if you want to" is a more expected workflow in general

[languid sail]

mxzf has the right of it; the flow of creating a new version to replace old versions, even if you then delete the old versions, feels more rigorous to us. We'd rather you create a new version, make sure you have all the data correct in the new version, and save that version (with the opportunity to fix incorrect data later) than constantly use the same version. I understand it takes slightly more time + effort, but we're currently not thinking of reverting this change.

[tawdry crystal]

Er, yeah. I'm not sure how to update my mod with the given UI. Previously I'd go to the most recent package version, change the version, hit save. Now I uh..do what?

[languid sail]

perhaps it needs more visibility, but there's an "add version" button on the top right of the versions list, above the buttons to edit and delete old versions

[tawdry crystal]

So I just copy/paste 95% of the data and drop the new version number there?

[languid sail]

If that's how you run your updates, sure

[tawdry crystal]

That seems needlessly pedantic

[deep bronze]

This is how I learn we could have just edited old versions?

[tawdry crystal]

For my mods I have one or two "permanent" versions that support a specific legacy system/foundry combo (so at this point they never change). Then I have "latest" which all I do is update the target version when I make a change -- what's the reasoning behind forcing me to re-type manifest/foundry versions/etc (or copy/paste) instead of just letting me hit the edit button that's currently there and changing the version (like we can on the /admin page)?

[languid sail]

To reiterate: this isn't to make you do more work or to tell you you're creating/updating versions wrong. This is to make sure that when you have a new version you have all the data correct there, rather than accidentally (for example) updating your V10 version to be your latest manifest, or restricting your latest version to V11 when V12 comes out unintentionally.
Perhaps we're wrong in the assumption that people like having a backlog of updates like we do for Foundry, and we can add that to the discussion if necessary, but for now we've landed on keeping the "rigourous" answer.

[tawdry crystal]

Well, I didn't use automation before, and I realize that was the hot topic for yesterday, but I'm going to jump on the "we need automation before /admin is obsoleted bus" if we're losing functionality

you have all the data correct there

And honestly I feel like this is backwards from how it currently is. I have the correct data there because it's already there. If going forward I need to re-input that data then I'm just introducing more cases where it can be incorrect ¯_(ツ)_/¯

[native lynx]

I was unaware of this technique also

@tawdry crystal and @worn mauve thanks for your feedback... this is good to know. We'll consider it and see if there is something we can do here

[left fjord]

I wonder if it wouldn't be a simple offering to add a "new from this version" button which would keep the most obvious data from the chosen previous version.

[tawdry crystal]

Yeah I'd be happy with that

[native lynx]

yeah. The admin edit technicque was convenient but it was definitely a hack

There may be a way to accomplish the goal while making it more visible and less... hacky

emphasis on may heh

[tawdry crystal]

It also seems like you're trying to protect us from something that isn't a problem (though maybe others have had issues with it). Realistically we're only creating links with metadata so if we fat-finger something we can easily change it -- this isn't the source of the mod as that data lives elsewhere so there really shouldn't be any permanent damage

[winged birch]

I will say, on a general technical level, pointing versions at latest has never been a particularly good practice. It's ideal to have specific manifest links for individual releases. I've seen a number of odd behavior come about due to modules just having a singular "latest" that they use for everything

[left fjord]

This is just me thinking outloud but---

if a button were added that would 'clone' the data of an existing version in the package listing except for version number that would probably give a 'best of both worlds' option

[vital depot]

that's not strictly true in the case of the Forge

since they're automatically polling for changes

[tawdry crystal]

The only issue I've ever seen from that is when The Forge somehow set up a pre-release mod as the "permanently latest" version, but that wasn't even (or at least shouldn't have been) on my "latest" link

[vital depot]

yeah the Forge's handling of versions is sometimes part of the problem, and it seems like involving them in this conversation would be important

[left fjord]

i'm pretty sure we have some forge people in here.

But ultimately this is about the package management interface on Foundry VTT.

[winged birch]

I've seen plenty of situations where a module update broke something and I had to inform users that they were basically out of luck 'til the module dev fixed it because there was only one manifest link available. It's not a constant thing, but I've seen it cause issues enough times that I won't do it myself. Having discrete versions lets people install whatever version they want

[languid sail]

Being not as fluent as the devs or longer-standing staff in Forge, I'll say my concern comes from the chance that between you publishing/updating a new version and fixing any incorrect data, you might have users update to the new version and get a downgraded experience.
But I'm happy to see how possible it is for a "copy" or "clone" button to exist.

[undone cargo]

Versions should not be installed via a “latest” manifest because then you cannot install older versions

A version should be installed from a version-specific manifest URL

[mellow bobcat]

As one of the abusers of the version change trick: I don't use a latest anywhere, but fixed versions in all of those links. Which also means that changing a release's fields amounted to a predictable "increase the last X numbers of the same version string in all fields by Y".

[deep bronze]

A handy "copy row and string replace" would basically replicate what I always do as well

[native lynx]

yeah I think that the "latest" issue and "the previously existing hack to avoid some data entry doesn't work in the new interface" issues are related but separate

and... less data entry is good, so, if we can manage to prevent it, great

[winged birch]

Yeah, they are technically two distinct things, it's just the venn diagram of the two overlaps pretty strongly

[vital depot]

yeah if I publish version X.Y.Z my urls are github/user/module/releases/X.Y.Z/module.json and github/user/module/releases/tag/X.Y.Z

having a way for the interface to auto-fill that would be handy

especially since that seems to be the recommended best practice?

make it easy for us to do what you want us to do

[tawdry crystal]

I can already see myself writing an AHK macro to just grab the latest values, replace the versions in those strings, and fill in the fields

[undone cargo]

There are some risks of autopopulating the form, which I hope everyone can acknowledge and appreciate

[tawdry crystal]

Definitely, but I think it's a bit more risky to fill out the urls every time (though realistically there isn't a ton of risk with that either)

[undone cargo]

As the designers of the system, if version data is wrong we would like it to be because of user error, not because of our error

[winged birch]

Personally, I always just copied them from my release each time anyways. It doesn't take super long to right-click, copy link, paste for two links from my release to the admin page

[vital depot]

I think both approaches are trying to manage risk; you've got people testifying that they're more reliable with automation tools than manual usage

[undone cargo]

That’s true but automation tools are a separate topic from the behavior of the “New Version” form which is inherently a manual workflow

[worn mauve]

I think that being able to see the previous versions while creating a new one would be good enough. So we can ctrl-c ctrl-v and change the urls more easily

[glossy rain]

Okay, have used the new interface now, and it is a bit more awkward to use. Previously I could just grab the lines from the fields above and change my version number in the manifest field, now there is a lot of scrolling, highlighting and pasting, rather than just double click and yank. Nothing major, just a bit more frustrating.

[native lynx]

thanks for checking it out and sharing your experience!

[umbral palm]

Looks like it's been said already, but being able to just edit the version number like we could previously would be nice. I feel like I'm more likely to cause an error if I have to copy and paste a bunch.

[lethal estuary]

huh, and im over here always copying from my release page urls/artifacts -- cause copying a previous version's line and tweaking a single number feels more prone to error than copying a whole, discreet URL 😅

release notes on release tag/page, and manifest attached as artifact there 🤔 just two copy/pastes

on topic, if nothing else, the facelift is nice and feels a bit more responsive than the older version. I dont think this impacts or changes any of my workflows, so it gets a 👍 from me -- edit: oh, duh, a definite, 100% improvement: accessing the package management page from your foundry profile page is a win. Its not unlikely i overlooked a similar link for the previous version, but i just ended up bookmarking the admin page so i could find it quickly.

[hushed bloom]

If this is not recommended, where is documentation on how to do a module release on git that actually supports this?

Consider this:

• You're a new dev, just happy to publish a relatively simple module or two. Maybe 1 person will find your creation useful!
• You support a system that advances at the speed of 100 owlbears.
• you do a release for each version, but since no one taught you how, your releases append the version number after the package number. Meaning that no official release is plug and play in foundry. Whereas the "latest" will be (no version number appended).
• by this method you support the latest version of the module, which targets the current (at the time) version of core and your system. People can download no problem.
• If for some reason someone doesn't want to update, then good news! They still have old releases of modules on the git to download, they just have to do a TINY amount of extra work to get them.
• because of all of this, yes, the latest version info is always the same except the version number

I get at one level this is just asking me to make a new version and copy and paste OR use a to-be-added feature to auto-populate that info, not a big deal at face value (and certainly less effort than writing a wall of text, that is not lost on me). But to me, the underlying assumption here (and now spelled out) is that i'm doing something wrong by using the latest version. But I don't think I am. This is talk in an ideal world where developers know everything, but I spent over an hour trying to figure out how to fix my old release names when i started doing module development . i could not figure it out and i rationalized that it would be more effort to learn this then put the marginal burden on a user who is trying to use an old version of a system (which is neither recommended by me nor something i want to support).

So,

• where are module developers given the resources to do it this recommended way? (I.e. build a release that doesnt append the version number to the module folder)
• and why are module developers assumed to support users they have no interest in supporting?

This assumption does ask more of community developers, and i don't feel you're supporting community developers in a way to achieve this assumption.

[delicate trout]

A good starting point for a new module is https://github.com/League-of-Foundry-Developers/FoundryVTT-Module-Template

[hushed bloom]

Thanks but you have only proven my point (and not read my comment)

You can use the url https://github.com/<user>/<repo>/releases/latest/download/module.json to refer to the manifest.

[lethal estuary]

You can, but can also refer to the release tag artifact directly, which is my general approach

[hushed bloom]

But when you download my releases from gitlab they append the version number. I have releases, they just don't plug and play with foundry

[lethal estuary]

Ah, gitlab, no advice there, sorry. I cannot figure out that platform 😅

[mellow bobcat]

I'd recommend reading at least parts of the linked repo's readme, which explains where not to use the latest manifest link.

The short form: in a release's manifest, it points the manifest towards the latest manifest, and the download to a specific release. In the package listing, enter each release with a link to that release's manifest, not the latest permalink.

What this setup provides:

• Users can install any version of the module, and trying to update will get them the latest release (pointing a release's manifest towards a specific version would result in never being able to update).
• Users can install an older version by using that release's manifest link (e.g. from the package listing or GH's releases page) – the manifest points towards a specific zip after all, and not the latest one. If a user then updates, see the point above.

As to "Why would I ever want to enable any user ever to install any version that is not the latest‽": so that a) users can install releases compatible with older core versions if desired, and b) to enable easier downgrading in case a newer release breaks something the user immediately requires. The effort to make this an absolutely painless endeavour for users is close to nil with the above setup – the version/manifest handling happens automatically.

[hushed bloom]

And how do i release a version that, when downloaded, doesn't append the version number?

I'm not against any of this but https://foundryvtt.wiki/en/development/guides/releases-and-history is a bunch of stuff i don't understand to solve a problem I'm not particularly motivated to care about

[lethal estuary]

That's gotta be something gitlab is doing

[winged birch]

Versioned release artifacts work fine on GitLab, I have all of my packages set up that way, with a CI setup such that I just make a new tag and it packages a release for me

[median python]

Also keep in mind that the wiki is a community-written resource that can very often be significantly out of date (like the article you linked) or even flat-out wrong at times.

[echo crown]

A little bit of feedback:

• When clicking the edit button of a version, a notification saying "Package <name of the package> was saved successfully" pops up (on the page for editing that version). Does that mean, when clicking the edit version button, the form is submitted (potentially applying changes, or adding a new version)? If so, to me, that's quite counter intuitive. If not, is the notification being shown incorrectly?
• The check boxes have very bad contrast. (see the attached screenshot) I guess, you can still see whether or not it's checked, but the low contrast between the checked checkbox background and the check mark are really irritating to my eyes 😅 . I can only imagine that it's even worse for people with vision impairment.
• I have noticed that it's actually still possible to change the version number of an existing version. It's a hidden form input, so if you change its value in the dev tools, you can still change it (I have verified that it works). If you indeed want to prevent that, I'd suggest to either get rid of that hidden field (if that's possible), or add server side validation that it is still the same as the previous value.

Aside from those remarks, I think it's pretty neat. I like it.

For those who are interested: Foundry Publish now supports the new flow as of version 2.4.0 (2.4.1 contains a small improvement). It still uses the old flow by default for backwards compatibility, but you can opt into the new flow by providing the --useNewPackageAdministrationInterface command line flag, or setting the FVTT_USE_NEW_PACKAGE_ADMINISTRATION_INTERFACE environment variable to true.
When using the new flow, you now need to specifiy the package id in the format of the id from the manifest, instead of the numeric id, which was needed for the legacy flow.
See the updated readme for more details.

// cc @errant anvil

[errant anvil]

❤️

[languid sail]

Thanks for the feedback! I'll note these things and get to them as priority + time allows
And thank you for updating your package, it's obviously a high need that we won't be able to fill immediately 🙂

[nocturne hawk]

I've scrolled through this thread and I don't think this has been covered already. But it looks like the new form doesn't allow you to edit packages where you are not the primary author of the package. My use case here is that I am a "developer" of Limithron and do all of the releases for the Pirate Borg system, but I am not the primary author of it. The Pirate Borg system (and packages) show up to me in the old /admin endpoint, but not in the new /packages one

Apologies, found the references to this in the thread already

[undone cargo]

we deployed a change on Friday that I believe fixed this. Are you still experiencing this problem?

For packages owned by a certain content provider you can access them via https://foundryvtt.com/creators/limithron/edit/

[nocturne hawk]

This one worked. I hadn’t found that part of the thread when I wrote the message originally sorry

[nocturne hawk]

If the change is meant to make them show them in my section, then that isn’t working. But I assume it’s not meant to be there

[languid sail]

Yes! I decided not to put it there and instead to open up the creators page for developers. 🙂

It's a little bit more work to change the /me/packages page, so we can add it to our roadmap if it's more requested

[nocturne hawk]

What about a link to the creators that you're part of? So my packages page would have a single link to the limithron edit page (rather than you needing to rebuild the full functionality into my packages page as well)

[languid sail]

There should be a link to your creators page at /me/content-providers/, it seems that was a miss when we added developers to the edit page

[nocturne hawk]

I see an icon, but no links. A link here would be perfect imo

[languid sail]

I see, I'll fix that for you as soon as I can 🙂

[languid sail]

When clicking the edit button of a version, a notification saying "Package <name of the package> was saved successfully" pops up (on the page for editing that version). Does that mean, when clicking the edit version button, the form is submitted (potentially applying changes, or adding a new version)? If so, to me, that's quite counter intuitive. If not, is the notification being shown incorrectly?
I can see this from both sides. We didn't want you to lose work on the package by clicking the edit version button, but I also recognize that you're not hitting "save" so you may have unintentional changes (such as adding a new version). I'll pass this feedback to the team and see what they think

[echo crown]

Yeah, when I noticed it, I also had the same thought. Not sure if there is a perfect solution.

[lethal estuary]

Just used the interface to release a package. Couple notes from actual usage (compared to first impressions from the other day).

First impressions hold -- cleaner, more responsive, and unified (with the rest of the site) interface 👍

UX notes:

1. The input text fields could use more contrast with their input background. It was a little tough to read.

2. URL input fields and url lengths. It would be nice if the url fields were wider...or otherwise was able to show the full string entered (maybe "echoing" the current input value on the next line?). The previous interface had a similar issue, though i think its input fields were a bit wider by default. Overall, not a huge issue.

[winged tapir]

Some instruction would be useful. All I see is "a new "Edit" button is now available" on the announcement page. I clicked on that edit button and I'm not sure what the expectation is. I updated the Notes URL to my new version, but don't know how to update the version itself. It still shows as 1.81.1 even though my latest release, and the one specified in the module.json file, is 1.81.2. I ended up going back the old admin panel to make sure it got updated.

[median python]

The expectation is that you’ll hit the “+ Add” button in the upper right of the list of existing releases, to add a new one with a new version number.

[winged tapir]

Good to know. That wasn’t required on the admin site, and it seems unnecessary. I rarely want to expose more than one release at a time. Isn’t that going lead to a long list of releases, where a lot of them are mostly the same expect for bug fixes? Regardless, specifying that somewhere would be useful.

[median python]

I think what has ultimately confused the issue for many people was the fact that you could just edit an existing release forever on the old site, never making a new one. That was kind of an antipattern, that everyone’s being steered away from with the new UI. You can of course always cull releases you don’t want anymore at any time.

[vital depot]

I just delete the old releases after I make the new one

[magic pasture]

I haven't read all the 200+ messages in this thread but i'll provide my feedback on the new interface. Of curse i have a lot of packages (as do a lot of premium content creators, mostly map related content) so an efficient use of space is a priority for a good interface for me:

• The /packages page has a lot of empty space. I don't need the manifest\project url buttons. Compact the interface so it's only a single Row. (included one row example image)
• There is no searchbox, there is no recent\alphabetical sort toggle
• Regarding the /edit page. I feel like the most frequent thing you'll do in this page is add\edit a release and hit save. The release list should be at the top in my opinion aand a save button should be somewhere at the top of the page. This way you can immediately open the page, add the release and hit save without the need for scrolling (image included)

[winged tapir]

I understand the thinking, but if data shows that most people just want to edit one releases why not let them do it? What is Foundry gaining by forcing people to do the extra steps of “delete and add” vs “edit”? It’s a classic case of trying to enforce an ideal in contrast to what people actually want. Check out “desire paths”.

[winged tapir]

That’s just busy work. The UI is making you do extra steps for no real benefit.

[median python]

Staff have already commented on this here: #1169350879334379611 message

[winged tapir]

Thanks for pointing that out. I'll just say that it's their product and they're certainly entitled to do what they want with it, but it's exactly this "correctness over convenience" philosophy that's turned me off of Foundry. I've gone through too many API updates that have broken perfectly working modules and systems in the name of correctness. The value that volunteer created modules and systems provide Foundry is imense, but us volunteer developers are not only not compensated in any way, but are forced to do extra work to react to those changes. I've already handed off one module to someone else to take over and I'm doing the bare minimum to support my other one because I just don't have that kind of free time. As a GM I've moved on to other VTTs as well.

[errant anvil]

Here is also a response to this forcing of making new versions

[errant anvil]

And here

[errant anvil]

However it's clear that making a new version for... A new version, is the wanted workflow

[median python]

There was also a “how about a clone-and-edit button” suggestion as a compromise if we’re bringing up the whole earlier conversation again.

[errant anvil]

Mhm.

[languid sail]

cc @errant anvil
I'm off duty today but this functionality is coming soon
(like, it's ready to be released, soon)

[sinful rune]

Hrm, I must have missed the fact that a new package administration interface was released.

[sinful rune]

@errant anvil I'll be updating fvtt-autopublish

[sinful rune]

To the devs, some comments:

• First off, thanks for designing package editing page in a way that uses "standard" browser features (POST forms, etc.).
• The "edit" buttons to modify existing package versions should probably be anchor elements, rather than buttons, since their primary purpose is to navigate to a new page. Doing so would enable right-clicking/control-clicking to open the version-editing page in a new window/tab.
• To build on the last comment, opening the package version editor in a new page with an anchor element would prevent the main editor page's form from being submitted, preventing unintentional submission of other field data.

[trail bison]

just to reiterate the points that with 50+ packagaes we need a filter and a search option urgently.
I also do not have access to the same things I have in the /admin page (das5 havena being an example) wjich may be because it is not released yet? but as the owner of the account I would expct to be there
Light mode- yes please!!!
Supported systems: again a way to quickly jump to the system (like in the admin page) would be great
have a "add update"/"add new from current version" button that prefills all fields and just lets me edit what I want to in the new one

[languid sail]

You should have access to all your packages through https://foundryvtt.com/creators/ulissesspiele/, the https://foundryvtt.com/me/packages page only includes the one you're listed as an author on (DSA5 Havena is under the UlissesSpiele Content Provider but with the author Huepfklotz )

Thanks for all the feedback! I've put all the things up to here either on our roadmap or to be discussed with the team

[sinful rune]

@languid sail Is the CSRF token in the module information administration page generated in the sent HTML, or is it given elsewhere?

[winged birch]

I can't imagine they're using something other than Django's native CSRF handling, which generally boils down to "stick {% csrf_token %} in the <form> somewhere and let the native structure do the rest"

[languid sail]

It'd be returned in the HTML, yeah

[winged birch]

Yeah, there it is, <input type="hidden" name="csrfmiddlewaretoken" value="...">

[echo crown]

It’s actually in there multiple times 😅

[languid sail]

yeah, that's a result of how we're injecting multiple forms on the same page
I believe it should be the same value? But I haven't looked too hard lol

[echo crown]

Yes, it’s the same. I just noticed it, because foundry-publish has a dry run mode, where instead of submitting the form, it prints the data that would be submitted. And I saw that the csrf token is in there 3 or 4 times. But they are all identical.

[sinful rune]

@languid sail Any other major changes for the main module editing page planned? Specifically ones that would change field names, form names, or required fields.

[real blaze]

I don't know if it's already been brought up, but the /admin package manager is much nicer to deal with if you are editing multiple package manifest urls at the same time.

When I release a new version I usually change the last version's url from latest to a version specific manifest. With the new package manager it takes a lot longer to edit multiple package urls as you have to do them one at a time

[winged birch]

Why not just use the version-specific manifest from the start? The manifest field in the manifest is the only thing that really needs to point at a latest URL

[real blaze]

Because foundry gives an extra warning when the url changes between versions, unless I am understanding things wrong

[winged birch]

Yeah, that's for the manifest field, not the URLs in the package listing

[real blaze]

Ah well TIL 😄

[winged birch]

Your original comment isn't wrong, you were just making some extra work for yourself

[languid sail]

Apologies, I was out until today; I believe everything's in a stable place right now, but there are some things on the proposed roadmap that may change foundations. If those things look realistic, I'll get in touch

[tawdry crystal]

The copy button makes it a lot easier to do things the right™️ way

So I'm good with it. It works well for the few modules I have. And having a direct link to it in an easy to get to place is a huge improvement over having to remember where exactly my bookmark is 🙃

[cursive jasper]

Considering that editing existing versions is not supported, what is the intended workflow if an already existing releases's verified version has to be adjusted up? For example if an existing version works both in v10 and v11 or more future looking if an existing release made for/during v11 continues to work in v12.

[median python]

Editing the compatibility metadata for an existing release has always been supported/recommended as a workflow.

It's publishing a new release by way of editing an existing one that throws a wrench in things.

[cursive jasper]

Ah I was misremembering that part, disregard then

[median python]

All good!

[neat dragon]

December is getting close - are there any news about the API?

[stuck wigeon]

Publisher handbook still links to the old package admin site

I'll make a thread in the appropriate forum channel

[languid sail]

Hello <@&596076164104323104>!

Thanks again for all of your excellent feedback about the new front-end package management interface!

Based on this feedback, we have deployed another round of improvements to the package management forms. If you have any further feedback that has not yet been covered, please let us know in this thread.

Some highlights of what we changed:

• Added a new Tools Menu that allows you to quickly access any links that usually would be hidden (such as editing a package from a package page, or generating or revoking content keys for premium content)
• Moved the package's "last updated" date time to correlate to when a package is approved or a new version is created to give content creators and users a clearer picture of when a package has truly been updated, rather than simply had a title or description change

Reminder: The retirement of the legacy /admin site for package management is scheduled to happen in one week on December 6th, 2023.

On December 6th, developer access to the legacy /admin site will be turned off. Developers will only be able to edit packages using the package management interface located at https://foundryvtt.com/me/packages and /packages/<package_id>/edit/. Improvements based on your feedback and our roadmap will continue to come, so stay tuned!

[elfin trout]

For anyone looking, that new Tools menu can easily be found in the top-left of the Foundry website next to the main menu and should look something like this on a package page:

[errant anvil]

Noticed these appearing 2 days after I bookmarked both of those pages lol, thank you for the quick access to these

[magic pasture]

I'm still begging for a search box 😅

[left fjord]

something something ctrl+f

XD

[magic pasture]

i want a quick search like the Github one

Not a press enter and wait for the page to load search :p

too many key presses lol

[winged birch]

too many key presses

I'm questioning your dev cred 😛

[magic pasture]

(() => {
    const search = document.createElement("input");
    search.type = "search";
    search.placeholder = "Search";
    search.addEventListener("input", () => {
        const query = search.value.toLowerCase();
        const packages = document.querySelectorAll("#package-directory .package");
        packages.forEach((packageEl) => {
            const name = packageEl.querySelector("h3 a").textContent.toLowerCase();
            if (name.includes(query)) {
                packageEl.style.display = "list-item";
            } else {
                packageEl.style.display = "none";
            }
        });
    });

    document.querySelector("#package-directory h2").after(search);
})()

i've solved it for now don't worry

xd

[neat dragon]

Do you have ETA for the API replacement?

Any kind, like "in december", "Q1 2024"

[left fjord]

February 2026

||joking||

We recognize the importance of offering an API; but we also don't want to promise that it'll be ready at a certain date and have that fall through. Best we can offer on a timeline for it is "It's being worked on and we'll let you know when it's ready."

[vital haven]

Soon™️

[trail bison]

This is pretty terrible for Sigil / Metamorphic tbh. All our release automation requires the API and this makes our lives a good bit harder. If at all possible, could you please treat this with some priority? For us, it is not a question of convenience... This will cost us actual money as we have to switch to manual across all new products and everything we want to update from our customer's back catalogue. So dozens of packages...
I am not sure why the interface/process changes are that important to do now whereas the API is a secondary concern, but I am sure you have reasons. I just want to be very clear that this hurts us more than a little.

[echo crown]

May i ask, how are you doing it currently? Unless I’m hugely mistaken, there currently is no API, so it’s just a change in UI. How does it actually make your life harder?

Please don’t get me wrong, I’m also a big proponent of automation and having an API for this (that why I have written a tool that can be used to automate this). I’m just trying to understand your position.

[trail bison]

We are actually using your tool, as far as I can tell (not the most tech person in the company :)) - but I am assuming your tool will need to be adapted (and thus not be usable anymore until that has happened) and an API now would be the logical step. Without an api and your tool we need to either create one temporarily or use manual until an API happens

I just wanted to point out there is a certain importance attached to the matter beyond convenience

[echo crown]

Currently, there are 2 tools that basically do the same thing: Foundry Publish and fvtt-autopublish.

I'm the author of Foundry Publish, and I have already updated it to be able to work with the new system. If you are using this tool, you can configure it to use the new way today.

fvtt-autopublish is maintained by @sinful rune. AFAIK, it has not been migrated yet, but it’s currently being worked on.

[trail bison]

Great news, we weren't aware of that being already updated - many thnaks for your work there 🙂

[lethal estuary]

It may be wise to look into your own solutions if sigil is entirely dependent upon an unofficial, community contributed tool

[weak kelp]

I#ve got still a big problem with the new me/packages thing.
I can't see the packages I made for Ulisses Spiele (content provider) neither can I edit them. But I still have to still manage those.

Would be fine if I have at least at https://foundryvtt.com/community/ulissesspiele/packages the "edit" button available.

but please don't shutdown the old admin interface until this is available

to my knowledge the packages I submit newly are also not visible on the content provider's side

[errant anvil]

Pretty sure that has to be done with Ulissess account specifically to grant you Editor and Developer ranks

[weak kelp]

I can already do it on the old admin page, right?

[errant anvil]

We've recently set up everything we needed for Loot Tavern and I have free access to everything with the above mentioned ranks, with my account being part of the Loot Tavern publisher account.

[errant anvil]

Perhaps a Migration issue (?)
Or lack thereof

[native lynx]

Thanks for letting us know, we'll take a look into your case and see what's going on here.

[undone cargo]

Your own personal user profile displays packages that you are personally the author of, not packages you indirectly have permission to via a content provider

[weak kelp]

but how would I access those

[undone cargo]

For packages you indirectly have access to via a content provider you can edit them via their individual package pages or via the content provider dashboard

[weak kelp]

what do you mean by that

I dont see any edit button

and what is the content provider dashboard

[undone cargo]

I’m on my phone in the car right now (not driving) so it’s a little difficult to provide documentation in this context. But I think your questions are revealing some shortcomings of discoverability that @native lynx and @languid sail can help to address

For a single package there should be a link to edit that package in the tools menu at the top left

You can access content providers you belong to on your user profile

From there you can manage any packages that belong to the provider

[errant anvil]

Go to your profile and at the bottom you have the content provider button

[weak kelp]

ah that works, but certainly not where I expected that

[weak kelp]

that's basically empty:

package page works,but still kind of inconvenient. would have expected it to work similar than before

just a list of modules I can browse through and find what I need

[errant anvil]

I have an Edit button down there but I can guess that's because I also have the rank of Editor

Which I arguably shouldn't have but I asked for just so we don't have to deal with permissions later on

I guess this is what would have happened if that wasn't the case

Once I go to the Edit button's page I can see all Content Provider packages at the bottom

[errant anvil]

Can you modify the modules from here? https://foundryvtt.com/creators/ulissesspiele/

[weak kelp]

no already tried that

that would be ok

thats wrong

it works there

[undone cargo]

Disclaimer: this is not the “official solution” but unofficially just add /edit to the end of the url

[weak kelp]

perfect thank you that is what I was looking for

i tested /packages/ulissesspiele

[errant anvil]

can you test what Atropos proposed because if that doesn't work I can see the issue here

[weak kelp]

the /creators page does all that I need, thanks 🙂

[errant anvil]

https://foundryvtt.com/creators/ulissesspiele/edit

If you cannot access the edit page, the issue here is that there is that you cannot edit modules unless you are also an Editor of the Provider's content

[weak kelp]

no, it's working now

but can't get there from /me/packages etc

[undone cargo]

Clearly we have some discoverability issues here which we need to continue working on, but you should have access as a developer in the provider to view and manage its packages from there

[errant anvil]

Alright, so this is just an UX issue of there not being an anchor to the edit page

[weak kelp]

that creators link might be helpful in the initial discord post

[undone cargo]

Crucially YOUR packages are , explicitly, only YOUR packages, so probably /me/packages should say that

You should have been able to get to the edit section of the content provider from your user profile

So that’s a missing feature / bug

[errant anvil]

yeah, that about sums it up

[weak kelp]

well that's why I tried https://foundryvtt.com/community/ulissesspiele/packages

next

but there I cant edit

[errant anvil]

Only editors have access to the packages UX-wise, when it should be also Developers

[weak kelp]

because if I go to /me it kind of redirects to that page with myuser name

ok well it#s there and it seems good on first glance. if you know where it is...

[native lynx]

Thanks for sharing your feedback, we agree that this could be made more visible and will workshop some potential changes to improve it

Very useful feedback

[weak kelp]

I would propose making this a link to the /creators page:

[native lynx]

Do you have access to the Edit Package menu item in the Tools menu for Ulisses Spiele packages, like this one?

[weak kelp]

yes, that works

[native lynx]

(you won't have the two Admin ones)

[native lynx]

That would be one of the most direct ways to get there, I think. Once the Tools menu is a bit more established / well known / in our Publisher / Developer on-boarding that will help maybe too

[weak kelp]

but I wont use that, the /creators page has all that I need

navigating between 50 packages with different pages each is too cumbersome

[native lynx]

yeah for sure

it's nice to be able to get there if you happen to already be on the page though

[weak kelp]

jup

[native lynx]

Cool. I've collected your feedback and passed it along, thanks again

[weak kelp]

thanks also

[sinful rune]

@undone cargo @left fjord @languid sail FVTT Autopublish has been updated to work with the new management interface. All a user should have to do is update the version of the GitHub action.

[sinful rune]

@languid sail Also, just an fyi, the package-description form is missing an id attribute. It kinda threw me for a loop, as the framework I use doesn't look at the class attribute by default.

[languid sail]

As in the package description textarea? Perhaps I'm misunderstanding

[sinful rune]

No, the form element itself

With the class "package-description"

[languid sail]

ahhh

Yeah I can throw an ID on that if it makes your life easier, don't remember why I put it in a class instead of an ID

[sinful rune]

I would appreciate it.

[sinful rune]

More specifically, it makes Autopublish's logic slightly less fragile, as it's relying on an id attribute, rather than the index of the form on the page or the form's class attribute, both of which are more likely to change.

[languid sail]

Hello once again <@&596076164104323104>!

I am happy to report that we have finalized our deployment of the package management interface. As scheduled, developer access to the legacy /admin site was disabled earlier today.

As a reminder, the new front-end package management interface can be found at https://foundryvtt.com/me/packages and /packages/<package_id>/edit/. You can also see all of the Content Providers that you're a member of and click Edit Packages to see a list of all Packages for that Content Provider.

Please direct any remaining feedback to the #1045406090285826158 channel, where it will be added to our roadmap and prioritized appropriately.

Official Package Release API

During the feedback process for this interface overhaul, we were given a lot of great suggestions. In particular, we heard your feedback on the desire for an official package publication API. As a result of this feedback, we have exciting news to share: we have published an official Package Release API!

To read more about this and learn how to start using it, please check out https://foundryvtt.com/article/package-release-api/.

[neat dragon]

https://tenor.com/view/yas-oh-yeah-gif-12490998435707637511

[sinful rune]

Love the "dry-run" parameter. No more having to risk making changes when testing FVTT Autopublish

[languid sail]

as part of these changes, this has also gone live 🙂

should be package-form or something to that effect

[errant anvil]

With the official package release API, is there consideration for also including premium package support? (the uploading of zips to your amazon storage)

[neat dragon]

Thank you SOOOOO much

[languid sail]

This is something I thought about but wasn't able to get in for this version, but I can get it officially prioritized + on our roadmap

[errant anvil]

bless 🙏

Would be great to automate away the annoying part of going to a private github repo, downloading the release zip on slow internet, and then going to the foundry website and uploading the zip again on slow internet 😂

[echo crown]

Thanks for providing the API, it’s highly appreciated. I’ll soon update Foundry Publish to use the API instead of the GUI.

[sinful rune]

No more parsing HTML and handling form fields. 😛

@languid sail Regarding the explanation for the API's manifest field, it may be better to have a slightly more extensive explanation, as the "latest" manifest URL and a "versioned" manifest URL are things new package developers often get confused about. I actually have comments in Autopublish's code for myself, just to clarify these cases.
Something like:

The required string for the URL of your package manifest associated with this specific release of your package. Note that this is not the same as the manifest URL in the package's manifest file; the manifest URL in the package's manifest file should be a stable link that always points to the latest release of the package, while this URL should be a stable release to this specific release.

[deep bronze]

Some feedback after we played around with it:

1. please return a valid url.

2. it would be beneficial to specify the package name in the api call to make sure that you're not mistakenly updating the wrong package (the api key is used as a unique identifier but its not identifiable by hoomans, so very error prone). I am aware this is possible to implement by doing two requests and matching on the returned page but I'm not sure why they want to encourage two roundtrips if it can be done in one.

3. looking at existing widespread solutions and implementing their feature set would have been quite a good idea, the ability to replace versions / delete "obsolete" versions in ghost's `foundry-publish` is super useful for a content provider that manages dozens of packages and doesn't want to go through each manually to prune old versions from the package overview page

Also (4):

[echo crown]

I was about to ask a question similar to 3. from Zhell's message above: is there a way to get information about the existing versions, and delete versions, via the API? My goal would be to retain the functionality to delete „obsolete“ versions via foundry publish, even when using the API instead of the GUI.

If that’s not possible currently, please consider it as an idea. I'm aware that the API is in its early stages, so no pressure, just a suggestion 🙂

[undone cargo]

It was my initial guidance that the API should be create-only, no updates or deletes

We'll monitor that and consider adding additional scope in the future, but it was a conscious choice.

We definitely need to fix the return URL and I agree that we should require the package_id to be passed in with the initial requests, this is a really good safety measure that we should have included.

[neat dragon]

If you change API, please consider adding new version in a versioned URL

Like https://api.foundryvtt.com/_api/v2/packages/release_version

[undone cargo]

I think we'll probably give ourselves around 48 hours for feedback and bug fixes before we treat this API as "locked", but if we make further changes later on I do think we can version it.

[neat dragon]

Thanks!

[undone cargo]

We're not going to deploy "API v2" 12 hours after deploy V1 though, we're just going to change v1 based on this group's feedback

[neat dragon]

Yeah yeah, it was more like a half year in the future 😄

One thing - if we use Authorization header, some libraries and tools it will be Authorization: Bearer <token>, adding bearer automatically (which is stupid but it is what it is). Would you consider changing it to X-API-Key or something like that (or adding second way)?

For example, if you use tools like Postman you have to manualy add header cause it expect Authorization to have value of Bearer <token>

I like the API very much though

Thank you for implementing it

[sinful rune]

Just curious, why?

[undone cargo]

I feel that version modifications or deletions are non-standard actions which should not be automated.

a modification of a created version happens when the data was incorrectly configured in the first place - something that shouldn't happen when using an API

a deletion of a created version is a conscious (human) choice to remove access to content

[robust saddle]

I ran into issues when I updated.

Error encountered!
Debug information:
  Current page URL: https://foundryvtt.com/packages/***/edit
  Current page title: Foundry Virtual Tabletop | Foundry Virtual Tabletop
  Currently stored cookies: ['csrftoken', 'sessionid']
  Login cookie is present: False

Unable to find package configuration form.
Are login credentials correct?
The current page URL should be https://foundryvtt.com/packages/***/edit

[languid sail]

In Postman, choose API Key, Key: Authorization Value: {release_token} Add to: Header

[languid sail]

Thanks for the feedback, I'm not sure why it's returning 2 https now, probably a last-minute change that I screwed up. I'll fix it asap

[neat dragon]

Yeah, but some http libs are stupid

And if you are quick and see you need Auth header and you don't dig in into docs 😄

[sinful rune]

Odd, I'll take a look

[robust saddle]

It ran without error when I updated the FOUNDRY_ADMIN_MODULE_ID secret. I wasn't sure if that had changed somehow...

https://github.com/etriebe/dnd-randomizer/actions/runs/7131779143/job/19421402275 (Not sure if you can see this)

[sinful rune]

Could you try using commit a1b7f03e77e2a0909778a7cca08f57c796130324 and tell me if you still get the error?

[robust saddle]

How do I target a particular commit?

do @commitid?

[sinful rune]

Yep

[robust saddle]

Trying now

[sinful rune]

Oh, yeah, you have to do that. I'll go ahead and add some error handling logic to point that out to users.

[robust saddle]

Yeah, I didn't see the URL have the ID # anymore so I just use dnd-randomizer

Also, do we use Package Release Token at all?

OK, it ran without error but I don't see it get published

[sinful rune]

Ok, I think I fixed that. Try the latest published version.

I'll be unavailable for about 45 minutes (driving home), so don't worry if I don't respond immediately.

[neat dragon]

For some reason when running from my CI/CD curl eats the authorization and I get "Invalid Release API Token"

[left fjord]

dumb question but is it a 'didn't wrap token in quotes' issue?

(caveat: i do not know that you need to wrap your token in quotes)

[neat dragon]

I think its just curl being stupid

[left fjord]

sounds about right for curl

[robust saddle]

Worked brilliantly! Thank you for the support! This module is a huge help 🙂

[echo crown]

There is a very common use case for this though: removing an older version with exactly the same compatibility.

Originally, I simply kept all versions in the list, which (back then) resulted in the newest version being at the bottom of a pretty long list. The recommendation back then was to remove versions that are not needed, and only keep the latest one for each compatibility (or something similar). Since there is no actual choice in this pattern (just the choice to follow the pattern), it makes perfect sense to automate it, imo, and is a good case for a delete API.

That said, I believe the order of versions shown is different now. Not sure if it’s sorted, or latest added at the top, but either way, it seems like the original problem is solved in a different way now. So possibly, removing old versions is not strictly necessary anymore.

But I think it still makes sense to remove the „obsolete“ versions, in particular if you have many small releases. And I still think automating this workflow also makes sense.

I agree with modification part of your statement, mostly, though.

[neat dragon]

I ended up writing a PHP script that I can call that connects to my premium package database and makes a proper API call

[native lynx]

It's also worth noting that the Admin-based package management page had a relevant, built-in limitation that the new front-end form does not.

If you had (WAY) too many versions published, you could end up hitting this limit and being unable to submit a new package until older ones were cleared out (which may have required staff intervention at that point? I'm not sure, it only came up once during my tenure here).

The new front-end does not have this limitation... one of the benefits of the new system. So between that and the sort order improvement, culling obsolete packages may not really even be practically necessary now.

[undone cargo]

While I am in favor of package developers trimming the version history from time to time to make it more user friendly instead of this giant list of releases - I am not in favor of that being an automated process.

Suppose you released version 1.3.7 with a certain compatibility range and then you release version 1.4.0 with the same compatibility range. If your release workflow automatically deletes 1.3.7 then you may be leaving users in a bad situation before it is 100% clear that 1.4.0 is absolutely the right choice for everyone.

What if people try and update to your new release and something is broken (we all make mistakes!). If the prior release was automatically culled then you might be deleting the last working version of your module and replacing it with a broken one.

What is more, we don't offer an API to allow you to discover which versions and compatibility ranges are published on our website, so you would be having to guess about which versions to delete based on your own repo data which might not necessarily be in sync. Overall it's just not the right call for us to provide tooling for this, especially not right away and possibly not ever.

[echo crown]

I suppose, we'll just have to disagree on this then.

When you manually cull versions, you can run into the exact same problems. Either way, you’ll have to fix the situation manually afterwards. Similarly, even if you don’t cull at all, a bad version will cause problems and requires manual intervention. Regarding the last point: that’s exactly why I asked about the existence of such an API.

So in my opinion, none of the points you made are an argument against automating this repetitive workflow.

I fully understand that it’s not a priority for you right now, but I hope you’ll still consider it in the future.

[vital depot]

I'm confused why this can't just be a normal REST API with CRUD

[undone cargo]

I'm confused why you are confused about that given what has been said in this channel to explain the answer.

😉

[vital depot]

I get prioritization, but in terms of "eventually" being able to programatically discover the versions & compatibility ranges seems like a good goal

[winged birch]

That would be just a CR API though, rather than CRUD

[undone cargo]

#1169350879334379611 message

#1169350879334379611 message

[languid sail]

Hey <@&596076164104323104>!

Thanks for your feedback on our initial release of the Package Release API the other day!

Based on this initial round of feedback, we've made a few changes:

• Added a new required field "id" to identify the affected package in a more human-readable way
• Fixed the link that is returned on a successful dry run or save so that it is a valid link
• Added and changed a couple of error messages (mostly related to the new id field)

If you receive a 400 Bad Request error The "id" field is required, this is why. To resolve it, you'll need to add a new line in the top level of the JSON body. Here's an example of the new request format:

{
  "id": "example-module",
  "dry-run": true,
  "release": {
    "version": "1.0.0",
    ...
   }
}

This new id attribute is now included in our KB article on the new Package Release API.

Please note: as Atropos mentioned yesterday, the API is still so new and fluid at this point that this is considered a change to our initial API offering, not a new version of the API. In the future, changes such as this will be properly versioned.

[sinful rune]

@undone cargo For what it's worth, I agree with you regarding package version deletion. It seems that in the past, package version deletion was a workaround for what were arguably UI problems or system limitations.

[neat dragon]

Yeah, the biggest hurdle for me was adding new package version, if the public version list is crowded I can remove them every few months

[sinful rune]

Well, that's still what I would call "treating the symptoms, rather than the cause". The proper fix would be to present the version list in a better way.

[neat dragon]

In UX? Sure, but I rarel go there

And I do not think many people use that part

[winged birch]

It's one of those "when you need it, you need it" things

[magic pasture]

@languid sail I was thinking, i really enjoy the "Upload premium package" interface, with the automatic detection and release, and i think it would be great if the concept would be "ported" to the regular packages, Idea:

• Add a new "Create release from manifest"
• The user would paste the manifest URL, the website will parse it and automatically make the release.
• The package manager could automatically infer the release notes url if the manifest is a github url by pointing to the release
• Alternative (toggleable option) it would copy the release notes field from the latest release (as a lot of people have a single changelog file)
• Add a "changes" optional field to the manifest that will be used instead of what described above to fill the changes field
• This will ensure there are basically 0 human errors as it can also do checks on the manifest the same way the premium package upload does

[undone cargo]

There is one key flaw with that proposal. For premium content we are hosting we take responsibility for creating a versioned manifest URL which provides a stable URL for always installing that specific version. Extracting release details from a manifest alone would not contain a versioned manifest URL, although I suppose the tool could be made to work by providing such a url as the input rather than providing a file

[magic pasture]

The user would paste the manifest URL

The url would be the permalink generated (for example) in a github release, what we currently put in the "Manifest URL" field

By implementing this method, the system can also verify that the url is valid and the manifest is validated

[tawdry crystal]

Could the api include archiving packages instead of deleting them? Essentially add a feature to hide versions without then being deleted?

[magic pasture]

I'm a strong beliver that this package deletion\hiding thing is just to satisfy our developer ocd, realistically, it's very rare a user would ever browse the older versions in the package page unless un update broke something (in which case the user would grab the second to last release) or they need a version for a previous system version. The latter case which is more common imho (eg, dnd5e, user updates the module but not dnd5e) is kinda useless as the package page does not give system version compatibility information

[neat dragon]

There is a tiny issue in the docs, the return path ends with slash in reality https://foundryvtt.com/packages/drgh-test/edit/ while the docs show it as ending without one, like https://foundryvtt.com/packages/drgh-test/edit

I was writing integration test using docs and found that out then it failed 😄

[magic pasture]

I also wanted to add, that a "changes" optional field could be added to the manifest, this will allow the system to automatically set the missing field thus completely automating the release process with basically no chance of human error. This url to the changes could also be clickable within the foundry module management app.

[native lynx]

Fixed, thanks!

We have a redirect there so we sometimes don't pay as close attention to it as we should, so I'll check in on that part, but the docs should have the slash in place regardless.

[magic pasture]

@undone cargo As a continuation on the discussion above, i'm also noticing that if you upload a premium package you have to manually edit the package to add the Changes\Notes url, adding the "changes" field to the manifest would also allow full automation of that. I can open it as an issue on git if there is a repo for it

[glossy rain]

The "Last Updated" column or the box on the web page is not updating when I add a new version through the new interface.

[deep bronze]

This? If so, that's the system (for some reason).

[glossy rain]

Also, here :

[errant anvil]

Yeah, seen that happen with other modules as well

[molten seal]

Is it possible to reorder releases? I want to be able to add a beta branch for v12 but don't want it to be at the top of the list.

Also, I too am affected by the 'last updated' thing not changing

[languid sail]

I believe they’re sorted by version number in a couple user-facing places but not internally, where they’re instead ordered by creation date, so you could try that

For everyone reporting the last updated issues, I’ve logged it and will investigate asap

[molten seal]

It would be nice to have that ability then. I generally have a Numbered version (latest with a permalink), latest, and dev, but I want a new branch just for the v12 beta and that would currently show first.

[languid sail]

If it makes you feel better, you could set the minimum to v12 and it won’t be installed for users below v12
But i’ll log this as a feature request regardless

[molten seal]

Yeah it's mainly trying to avoid confusion for users that get that page

thanks!

[fallen cloak]

Hello everyone.

I've noticed something and wanted to ask if this is normal.

I have been using the Package Release API for my modules for a short time, since the change to the current version of course.

But now I've noticed that when adding a new version via the API, no message is sent via #package-release.

[languid sail]

I’ll investigate this, there shouldn’t be a difference using the API vs. the usual release process. Thank you for reporting it!

Would you be able to DM me which module(s) you’ve updated and noticed this with?

[fallen cloak]

of course

[tawdry fossil]

I would like to bump that, as I experienced the same issue. Module id chat-commander-wfrp4e, version 0.1.4 was released using API from Github Workflows (got it working after few mishaps), but nothing appeared in #package-releases

[languid sail]

Thanks! I'm still looking into this issue, the more info the better

[tawdry fossil]

Not sure what else I could provide, but if you need anything else I will be happy to assist

[quartz grotto]

@languid sail I had the same issue with the new package I sent. When I created the first version using the page, there was a message sent to the channel. However using the API didn't.

[languid sail]

Oh, I think I just realized what the issue is…. I’ll investigate ASAP so we can get this resolved

[vital depot]

One of those "out walking the dog" brain waves?

[magic pasture]

Still praying for a search box in the package list here 😅

[sullen spoke]

tbh, with the amount of modules I've made and am keeping up to date... that sounds like a good idea 😅

[magic pasture]

Like, i know we can just CTRL+F, but in reality i automatically search by module ID and the ctrl+f does nothing

I'll make a website feedback post

[languid sail]

pretty much, lol
I like when the background tasks of my brain finally find an answer to something

[languid sail]

Thanks for the feedback post! It's on our roadmap already but I don't have a good when/if it'll get done answer for you yet

[quartz grotto]

@languid sail was the possible fix pushed? We released a package right now and I saw that it didn't appear on the channel

[languid sail]

No, unfortunately when I fixed the issue another much more complex issue reared its head. I'm in talks with the team about either implementing a workaround for now or building a more permanent solution, and will post here when one of those two things have been implemented

[quartz grotto]

Is there any possible workaround for us to do while that is not working properly?

[winged birch]

"Make a post manually", I suppose

[quartz grotto]

I was checking exactly that, but some kind of possible automation... but that would require some work from the server administrators... so, it should not so easy

[winged birch]

No, I mean like you personally post in #package-releases saying "Package X version Y is now released". The bot isn't handling it, but devs have the ability to post in that channel

[quartz grotto]

I saw .. just wanted to do some automation... 😄

[winged birch]

Yeah, the automated side of things is down ATM, so manual is what it is for now

[tawdry fossil]

Well, if bot isn't handling the API releases you only can post manually, or manually add release via website manager...

[lethal estuary]

dropping a link to the github release notes would be easy and effective

or create the release by hand, ya

[languid sail]

Unfortunately it's an architectural issue, so I don't think there's a great workaround. I think we've come to a consensus what the fix will be. I'll be working on it today and tomorrow, and will give updates along the way since I know this is a very frustrating issue for folks to have to deal with

I'm grateful for every developer who's given me info about the issue, though, it's only through your reports that my brain could figure out what the issue was in the first place 🙂

[quartz grotto]

count on me for any help you need 🙂

[tawdry crystal]

Do GMs actually browse the #package-releases channel looking to see if something they've used is updated? I've never used it ¯_(ツ)_/¯

[winged birch]

Some people do. Not everyone, but it has a target audience

[vital depot]

Ideally whatever you put there isn't a ton of extra work, e.g. just copy + paste from existing release notes

[lethal estuary]

the package announcements have a changelog link already there 🙂

[deep bronze]

I check to make sure my releases come thru correctly lol

[sullen spoke]

I sometimes do that and sometimes don't ^^;

On the GM side I don't at all, but as a helper I sometimes do a quick check on a module that way.

[tawdry fossil]

well, as a module dev I am biased, but sometimes I lazily scroll through there to check if there is something interesting that's not purely 5e 😅 that's how I discovered Lock'n'Key, DFreds Effects Panel and Sweet Nothings...

But I imagine the average GM doesn't... it was different 3 years ago when there were only few hundred modules (iirc there were less modules then than we have systems now) so updates were much much slower and easier to follow.
But now, when you can get (on a busy day) almost a dozen or two of new posts every hour, I think most people stopped caring to check.

[strange basin]

#package-releases is one of the few channels i keep unmuted and try to skim through at least once a day, never know when you'll find something cool.

[tawdry fossil]

I almost wish there was separate channel purely for NEW modules (first releases etc.)

[deep bronze]

But the first release is never in that channel. 🤔

[tawdry fossil]

but it is? 🤔

[strange basin]

yea, not sure what you mean, mine was

[tawdry fossil]

#package-releases message < it was first release of my chat commander expansion module, and it showed

and I'm sure every single module I released always showed first release

[winged birch]

I imagine it makes a difference if you make a first release before the module is approved or not

[deep bronze]

Not if-- yes that ^

[strange basin]

oh, yea, i mean, my first github release wasn't posted, because during the approval process i made several more

[tawdry fossil]

I never was able to make a release before approval 😂 maybe changed now

[deep bronze]

Needs a version on the foundry page... no?

[winged birch]

Yeah, the version in the Foundry admin page is what matters (and IIRC you could do that as soon as you submitted it, as long as it wasn't your first package ever)

[languid sail]

(This has changed recently, and now your first release will be put in the package release channel upon approval)

[languid sail]

Update on the #package-releases issue:
We're working on deploying the first half of the fix. The second half is a larger architecture/infrastructure change so the timeline on it is murky
For now, if you need to post in the package-releases tab manually after using the API please continue to do so, and if you'd prefer not to use the API then continue to use the packages edit page in all the different forms you can get to it.
Someone from the team will post here once we get a better sense of when the full fix will be deployed

[languid sail]

Alright, we have the second part of the fix planned out and I have a change going for it. Upon the deployment of this change, the API will automatically post the discord announcements for version releases again. Thank you for your patience as we get this worked out, I suspect we should have it ready to go within the next few days, earlier if possible.

[young helm]

I've just made a new release and it went through, but I've received a {"error":"no response received"} for some reason https://github.com/mclemente/healthEstimate/actions/runs/7661462895/job/20880905825.
Posting to check if it's the API not returning by mistake or somehow my release workflow is flawed in some way

[young helm]

Just made another release on another module with the same workflow. It got through and threw no errors

I guess it was just a hiccup somewhere or Magpie turned the API off and on in-between releases

[languid sail]

Apologies, missed that message. I suspect it was a server hiccup, but if it happens again please let me know

@here Good news! We have successfully deployed the API changes that have fixed the discord webhook announcement!

If you continue to have issues with deploying your packages, either through the API returning a failure, or through not seeing the Discord announcement, please let me know.

[quartz grotto]

Thanks for all the hard work @languid sail!

[warped pivot]

I maintain a single package so the Release API is not super useful to me, but it's straightforward enough that I might still use it in my releasing pipeline.. Good stuff!

[buoyant mulch]

Thanks to Discord's search feature not being up to par I'm not sure if anyone else has pointed out that the package release dates don't seem to be appearing correctly? I have multiple packages (including one I took over) where the update dates aren't being reflected on the package page.

[strange basin]

both of my modules I updated today and the last updated display on their package pages is both correct (releases created with #dev-support message this github action) 🤔

[buoyant mulch]

Interesting, in my case a package I took over and made a new release for still shows "Updated 2 years ago" - https://foundryvtt.com/packages/swtextcrawl . Along with others I've updated in the last few days or weeks not showing a newer updated date.

[strange basin]

are you manually creating the release on the package page then? there was some behind the scenes work recently to get the release creation REST api posting to #package-releases again, might have introduced a regression for manual release creation somehow?

[buoyant mulch]

Yeah these releases were all manual and not using the API as part of a CI process

[strange basin]

something @languid sail might want to look into then

[vital depot]

Can confirm manual regression: https://foundryvtt.com/packages/knw-actors

New version today, but "updated 3 months ago"

[languid sail]

https://tenor.com/view/link-broke-vase-it-was-like-this-when-i-found-it-gif-10594085

Thanks for the report, I’ve seen this off and on and wasn’t sure if it was a real issue. Might not have time tomorrow/over the weekend to fix it but I think it’s a big enough problem to hop the queue if I can find the source

[vital depot]

❤️ Thanks Magpie for all your work

[languid sail]

It looks to me like the package version dates might be correct while the package itself might have the wrong date? Somehow out of sync. Anyway, if that is the case I’ll be sure to update the package date

[delicate trout]

I noticed this problem too, with my most recent releases. How does a release get a date at all?

[vital depot]

Usually by asking nicely and not being weird about it

[languid sail]

There'll be an easy way to backfill this data soon, but all new package releases either through the manual edit page or the API will be automatically given a release date by the date the release was received by the server. This should (if it were working) then automatically tell the package when the most recent update was

[delicate trout]

For my PDF Pager module, it is showing the last update of 3 months ago, but 0.50.0 (the latest in the list) was released on github only 2 weeks ago. So I don't understand where it is getting that the 3-month-old data from.

[tawdry fossil]

I think it's the last time the module's description was updated

[past river]

@languid sail It seems I can't submit my module. When submitting it should go to the edit page, but it gives a 404 error, even though a notification says it's submitted. It also doesn't show up in the user page packages list. I tried Firefox and also Edge, same thing.

[past river]

Oh, and I just saw a that I also received the automatic confirmation emails, but with broken links

[languid sail]

Can you send me the module id and manifest? I’ll see what’s wrong as soon as I can

[languid sail]

Yep, this is my bad. For now hold off on submitting the module, I don't know if I can get a fix to the website over the weekend. I'll post here when it's for sure deployed

[languid sail]

I pushed the fix for this issue yesterday(? time isn't real), now when you submit a new version it will update correctly. I wanted to also backfill the data along with the release, but didn't get a chance to before the weekend.

[delicate trout]

Ah ok, I will check next time I update a module.

[languid sail]

alright, this is now fixed! Go ahead and submit your module and it'll take you to the edit page properly so you can fill in the details

[past river]

Yup, it works now! 👍

[tawdry crystal]

What does it think I just submitted? I hit copy on an existing release, updated the manifest URL, then input the Version Number and hit enter

Ah, I see the refresh button above the Add Version "form". It looks like those need to be separate forms as right now there's just one form for the whole page

[languid sail]

So when you hit enter in Version Number it thinks you’re refreshing your token? Hm. I’ll fix that

[tawdry crystal]

Yeah, that's what I saw

[plucky walrus]

Releases for my module (https://foundryvtt.com/packages/oronder) stopped showing up in #package-releases, but my call to the release API returns a success. Here's my build script: https://github.com/oronder/Oronder/blob/c5a1f8f67cdd6c6ac24d29b6c18543252b7d216f/.github/workflows/foundry_release.py#L23-L45

[languid sail]

Hm, I'll have to look into this. After a cursory inspection of your build script, though, I suspect it has something to do with you both submitting a package update and a package release in close proximity. Perhaps add an artificial delay between the two updates and let me know if that helps? Otherwise i'll get to this tomorrow

[plucky walrus]

Even w/ skipping the package update it doesn't post to the channel
https://github.com/oronder/Oronder/actions/runs/7780733500/job/21213923796

[languid sail]

I figured it out, I'll DM you

[young helm]

am I blind or is there no way to manually archive a package?

[vital depot]

There's not, which I think makes sense — if something is just no longer updated, the Foundry standard is to leave it up for people still on older versions

[winged birch]

You contact staff and they can archive stuff

Yeah, stuff gets auto-archived after being unmaintained for two major versions anyways

[vital depot]

There's lots of people still on V10 because they're finishing campaigns out

[vital depot]

Feedback on new package submission: The first line reads A new module has been submitted for approval and posting on the Foundry Virtual Tabletop website. You can review and approve it here: https://foundryvtt.com/admin/packages/package/4046., a link which is no longer useful because it references the admin page that is not accessible by module devs

[median python]

That first paragraph is actually written to Foundry staff, who are the "you" in there — you're just being CC'd on this email.

(yes it's a bit weird)

[vital depot]

to line has my email, but it effectively being a CC makes sense

[median python]

Yeah it's always been this way, and has always confused people, so it's a fair shout. But yeah, the package admin page does still work for them, so. 🙂

[vital depot]

Lucky them 😂

[languid sail]

We're planning to rework that email at some point, I just haven't gotten around to it 😅

[vital depot]

Great, just wanted to make sure it was on your radar

[tawdry crystal]

This is a problem again (maybe still? I thought it was fixed, but it's doing it now)

[tawdry crystal]

Is there a better place to report this issue?

[native lynx]

Are you still having this issue? And is the issue that you want more space between add release and another button?

#1045406090285826158 might be a better place to discuss this. THis is an old and easily missable thread (that should probably be archived at this ponit also).

[tawdry crystal]

It was happening 5 days ago, I don't have a package update right now to try again with. The issue is that when hitting enter within the "Add Version" inputs, the page thinks I'm hitting enter for "Refresh" because all of the inputs within the page are within a single form.

[native lynx]

yeah, I'd definitely create a new issue in #1045406090285826158 with as concise and exact steps as possible, along with a quick description of what is currently happening and what you expect to happen.

[quartz grotto]

Hello, it seems that this issue is happening again

[undone cargo]

Can you re-state the problem please

A lot of time and context has passed

[quartz grotto]

Creating a new version of a module/system via the API is not sending the notification on the #package-releases