Arsalan, I see your point. Let's go ahead and add OSSN Version and Works/Doesn't Work with Current version to the response just for good measure. I can see that most of the null comid are language packs with only a few being components or themes. Do the language packs get treated differently somehow or something? My limited experience makes me guess that they don't and they have a comid just like everything else. I would be happy to download and open each one of these and provide you with a com_id and version for each so that we can have a complete library.

We're you going to add a required field for new components for the com_id?

Hi Bryce, i haven't thought on making part of core as we have many translations and if we add more stuff in core we surely need a text for feature. So if we leave those translations untouched and add English langauge only it will look like broken.

What i mean is its not easy to translate any new component we add into core in other languages. (Like i can add Pages into core but who will translate except English and German?)
.

If you wanted me to add Works/Doesn't Work with current version of OSSN let me know i can do that for you.

Regarding v5.x yes its and other thing that need be addressed.

Arsalan, that is awesome! Thank you so much. What do you think of Z Man's commont on making this a part of OSSN core? I still wouldn't mind contributing if it was wanted and I could do a PR into the OSSN code on GitHub but I totally get it if you guys would rather not have outside help, especially from a OSSN noob like me ;)

Also, is it too hard to add the version of OSSN that the component is compatible with like the 5.x for example. The use case for this would be that say I have version 1.2 installed of Component A and OSSN v4.6 installed. Then Component A gets updated to v2.0 but requires 5.x. I I wouldn't want to flag that as having an update available because I don't have 5.x which is a requirement if that makes sense. Also that flag you guys have that says "Works/Doesn't Work with current version of OSSN" would be cool too. Anything else you could think of? I noticed a lot of null com_id and versions too,is there anything we could do to get that info filled in somehow? Let me know your thoughts on me contributing and adding this extra info in the API response. Thanks man!

@Bryce as promised : https://www.opensource-socialnetwork.org/wiki/view/3763/community-components-version-updates-api

We always wanted to help people like you , who really wanted to do contribute and do something. 😊😊

There is no need to apologize. You may reply to that ticket and i shall answer your question there.

@Bryce, i am currently looking into that and will try to revert back in 1-2 days.

@Arsalan,

Apologies for incorrectly posting, but there was no direct indication that it was for "free" components only and it had bearing on my question. Apologies again.

However, in my defense, if one is required, I did mention this very issue in my last post in my ticket to Softlabs: Friday 25th of October 2019 02:28:11 AM, but that ticket was recently closed, as you know and the question was not answered.

My question is still outstanding....I shall raise another tick in due course and not do so here.

Thanks

@Steven, you assumed correct and please start your own topic regarding non free version issues, here its only being asked for OSSN free. Regarding your question. Ask on correct channel. The latest update you see are not the version update unless you see new version. They are the builds which the same version is build again by system from the private repository.

I would assume that such a component would apply only to the "free" components available within the community and not for the "Premium/Hosted" components as supplied by Softlabs??

There is an issue whereby, having purchased the Premium product, any components therein cannot be then downloaded if there are updates to those components....and whilst the update to the Premium OSSN lags behind.

For example. [Ossn Component]Site Moderators, a component that comes with Premium or can be bought separately, was updated:
Latest Version 3.3
Last Update 1 week ago

Yet, the Premium OSSN is not updated to compensate for any such component updates.

You then have to wait for the premium OSSN update that will contain, one will assume, the new updated component.

Component updates (Premium/hosted) are out of sync with updates of premium OSSN, which premium users do not have access to...therfore in this case a component to tell you there is an update would be of no practical value to premium users..... I would guess????

That sounds good to me if it were a part of OSSN core and honestly I think that's it's best implementation since then the code for the OSSN site API or whatever gets used and the update tool would be in the same hands under the same control. I would just like to see it implemented sooner rather than later meaning I would hate to see this kind of functionality get shelved and take 2 years to complete ya know. I don't know what's on the roadmap and what's a priority and it's really not my business but I just hope it would get picked up sooner. Thanks for the input

Nice idea,
and honestly I would prefer making this a core part of Ossn.

As for the API: I think, it's already in place. Almost. Having a look at my Admin panel I can see My Ossn Version and Available Updates.

Thus, it would be sufficient if Arsalan creates a cron job looping in intervals through the component store and save the available information in a JSON file.

Back to my site's admin panel, this would grab that JSON structure, and on opening Components->Components we could do a comparision and mark outdated components with a different color, an alarm clock ... whatever. On uncollapsing the component entry we could have an Update button and upload the latest zip directly from the store if conditions fit.

As for making things foolproof: Basically we have already all parts in place. The component's name, version, and Ossn version (which would need a little refining to allow precise numbers instead of just 5.x). We might add a field for the component id, yes. Then it just needs straight discipline to enter exactly the same here compared to what has been stored in the xml file.