then when you click on one of the products, let’s say, PrettyScope, it will take you to this page where you can find all old versions of PrettyScope. The parameters for this should be. version name, date, changelog text, and download link.
Your base item is then “One version of an app”. So you have a “Versions” collection gathering all versions of all apps.
Then you have an “Apps” collection, where you reference apps by their name. This collection is referenced in the Versions collection, so for each Versions Item you specify what app it’s about.
So you can have an Apps Collection List on your dashboard page, listing all apps, and when you click on one, you end up on the Apps template Page, and you can have a Versions Collection List listing only the versions of the Current app.
I can see why this database can be a struggle to design. Because you’re trying to use your Apps item as the base item of your CMS (the smallest node). And you end up with solutions with a ton of fields. That’s quite natural to think this way.
To find the best design for a database, the key is first to identify what the base item will be. When you’re facing a cumbersome solution with multiple fields, it maybe mean that your base item should be a smaller portion of data, like in your case, a version instead of an app. That’s actually what you produce and distribute: a version of an app.
Thank you for such fast reply, Vincent! I believe by following your idea I would still have to make tons of fields for versions. A plugin in the long term can have hundreds of versions.
For each version it would be 4 identical fields “date” “version number” “changelog info” “download link” so I would either have to duplicate those fields with different names “date1” “date2” which would be bad or hmmm I don’t know!
I am honestly very confused and I think I would be better off making individual pages with no CMS at all.
Would be so great if it was possible though. Let me know if I misunderstood your reply!
Field? Do you mean Items? Like a new item in the collection.
Yes you need to take the volume in count.
How many pluginsfor how many version? What would the total amount of versions, app apps?
No! That’s a normal process, a normal design for a collection. You name the fields for what they are, “Date of release” etc.
If your goal is to regret in a few days, absolutely
Tell me about the volume and let’s find the best data-design for your CMS.
Think about this also: data-design is also answering the REAL question about your activity. Like if your listing of version is really long in the end, you can wonder if all those versions are really needed. Very often we want to fill a database with too much, unneded information, just because we can. Finding a solution for a good data design implies dealing with the reality of things.
With the CMS hosting, you can have 200+ versions of each plugin with the system I described.
With Business, hosting, 2000 versions of each.
So, there’s room isn’t it?
You can also have other collections referencing the platform, the host software of the plugin (if any)… any other haracteristic you’d like to be able to filter on.
Is this the way to go? I feel like there must be a better way making fields for each version seems a bit inconvenient and confusing in the long term when there are many.
Thank you for your patience and help so far, Vincent!
I tried dropping a Versions collection list on the Plugins template page and applying a filter to show only the product on that page. This actually gave me an idea of just having a single page for all versions and not have pages for each product. Maybe I should do that!
So, instead of a dashboard. I will just have a list for each plugin with all the versions. I can divide it by sections and have links on top that will take you to the plugin you are looking for.
I think this would be the most convenient way for the user too!
Ok, not exactly that. I reckon it may be a difficult concept to understand at first.
Your Apps collection has a minimum of one field: name. As many item as plugins. And no reference field.
Your Versions collection has a reference to your Apps collection. And you add your items there. Like one item is Prettyscope v1.0 (one title field, one version field that is a digit field) + RT for changelog.
So when you enter a Version item, you set its title, verion number, and you chose what app it’s about in the dropdown menu from the reference field.
This is perfect! That makes a lot of sense. Thank you for taking the time and explain it to me. I will now implement it and let you know if everything went well
Everything looks good so far! I have one more question, though!
Would it be possible to have a changelog dropdown for each item? I am afraid I have no idea how would I do that without opening all at once. I would like to press on one and just open that one.
The principle is that you’ll design your list items with the changelog text open like you’d like to see it open after the changelog word is clicked. So at first it will be visible on all the lines.
You’ll then use Interactions (IX2) to make the changelog text shrink to height:0 on load (affecting all elements of the class), then Interaction again to expand the changelog when you click on the word.
Along the way you’ll have to deal with IX to limit the effect of the expanding animation to only the desired element. Also if you want for one element to shrink again when you click another one, then uou need to start your IX by shrinking everything before opening something. You’ll discover all those options along the way, it’s a great case study to learn IX.
thank you so much for your time looking into this!
making fields for each version seems a bit inconvenient and confusing in the long term when there are many.
