Better Extensions page

MySchizoBuddy

• List dependencies
• List Dependency status. enabled or disabled. Each extension already identifies itself on conf/settings.php file. Other extension developers should look if the extension is enabled. If not change the dependency status and also disable the checkbox. Do not allow the extension to be enabled if it doesn't meet the dependency
• Optionally Auto enable dependency. Prompt the user whether he/she would like to enable the parent extension if the extension is downloaded but isn't enabled.
• Link to Support Discussion instead of documentation page or author website

Wanderer

Now we're getting somewhere!

Posted: Wednesday, 14 March 2007 at 12:17PM (AEDT)

y2kbg

wowo good thinking

Stash

1. Yes, but Inline Images is NOT dependant on JQThickBox :P
2. Couldn't we just lose the "support" link and have the extension name link to the addons site? That will now automatically give you the discussion for the extension as well
3. Would (disabled) change to (not installed) if you don't even have it installed?
4. Regarding the "Auto-Enable Required Extensions" - it could do it in the correct order, even going so far as to disable any already enabled required extensions and re-enable them in the correct order
5. Again, the name of the required extensions in the "Depends on:" line could be links to the extension page - this would aid downloading. Ideally you could just click and install...

MySchizoBuddy

1)Inline optionally depends on JQThickbox 2)well the authors have the right to link back to their homepage :) 3)sure why not. 4)that is going to be a pain :) 5)sure why not

Stash

1. I would disagree that Inline Images *depends* on JQThickBox for the very reason that is an option. It is certainly not a requirement for Inline Images to work (not like Attachments), so what is it? A partial dependency?

2. If that is a link to the author homepage, why is it called support? Surely the support happens in the lussumo community forums? Why not make the Author name a link to their homepage? That would make more sense to me.

4. I agree that is going to be a pain, but it would be nice It would certainly save having to tell people in the readme that they have to enable things in a certain order if it's done automagically

Mark

These are great ideas.

Another thought I had was to make the addons site let you choose *all* versions of vanilla that it works with - instead of just one.

Mark

The problem with doing this is that it will require a change to the information bit in the default.php file of every single extension. We'd need to list the dependencies there (with version) and we'd also need to list the Vanilla Version that it works with - so the system can know to disallow it being enabled ... or whatever...

Mark

I guess I could make the extension list look up the dependencies directly at the add-ons site. I just didn't really want to have that many pings to my server from 40,000 or so forums.

MySchizoBuddy

if JQthickbox isn't enabled the option inside Inline images should be disabled. Thats how it is now. the authors name is a link to its homepage, and support text links to support that can be done using Tier system. Parent extensions are Tier 1 and dependents are Tier 2. Automatically enable Tier 1's before Tier 2's are enabled. Why are we making it more complicated. Mark won't implement it, if we're asking too much. Forget about automatic enable system for now.

Mark

Unrelated thought - it would be cool if Vanilla didn't separate comments if there were three in a row by a single author

MySchizoBuddy

Mark we have to do this sooner than later. As extensions grow larger, it will be hell to maintain. we are already having dependency issues every where. People don't seem to read readme.txt. u have to force them to install the dependency. Its like having a house with all the doors open. If they are opened I WILL go in. If they are closed I will either knock or get a key. either way i know that getting in that room requires something etc from me. something i missed. Its the job of the extension developers to figure out the dependencies, and store the information in the default.php. what it depends on which version and where u can download it. Each extension developer can do this on his own. Unrelated Thought - it can be done using jQuery with little effort. only problem will be the abrupt jump of the permalink numbers. but that can be ignored anyway. plus editing the comment will be problematic. in which case u just display " u messed up buddy now u won't be able to edit. next time think before u make 3 comments in a row :P"

Stash

Also, what about conflicts?

...by which I mean incompatible extensions...

MySchizoBuddy

don't even go there Stash one thing at a time

Mark

@Schizo - We've made big strides in the last few weeks. These problems have been around for a while and we got by. We *do* have time to do things right. If I did this full time, it would be done already, but I don't. I just did a release of Vanilla, and I'm not planning on doing another one any time soon. You may be the exception to the rule, but 99% of the time people don't like upgrading web applications. It's typically problematic and nightmarish. The less I do it to them, the better it is for Vanilla as a whole.

So yeah, next release we can certainly overcome these hurdles, but I'm not in a rush to get there.

Regardless, those of us who regularly update by SVN will get the new features faster. And adding another line to the newer extensions won't break old installations of Vanilla. So we can take our time with this and do it right.

Mark

I think the first steps really should be taken on the addons site.

For example, add the ability for you guys to create dependencies. That way I can automatically add links to dependent add-ons on the download page.

I think that's a good start, and I'm happy to work on that for the time being.

Mark

I should also mention. I think this looks fantastic:



I'll probably make it look just like that.

MySchizoBuddy

So ur going to put up official guidelines for new extensions and how to mention dependencies sweet :) plus make it for v2.0 :)

Stash

Another thought I had was to make the addons site let you choose *all* versions of vanilla that it works with - instead of just one.

I love this.

I think the first steps really should be taken on the addons site.
For example, add the ability for you guys to create dependencies. That way I can automatically add links to dependent add-ons on the download page.

And you could do it here as well?

As much as I love Schiz's mockups (he is the king), please do consider what I suggested for the links.

1. Currently the name of the extension is not a link and does nothing - why not make it link to the extension's Add-on Site page?
2. Then the author's name can link to the author's home page.
3. This then removes the need for the "Support" link and keeps things neat and tidy.
4. Also, linking the extension names in the "requirements line" as an anchor to that extension on that page (so the page jumps to it) would make it nice and easy to enable an extension that isn't.
5. Please can the "requirements line" update when an extension is updated so that it shows the actual status of the extension in question?

Mark

why not make it link to the extension's Add-on Site page?

The reason I didn't do that before now is because the default.php file doesn't contain the actual AddOnID in the database - so there's no way of knowing if that add-on actually exists in the addons site. For example, I've got a few custom ones here that don't exist on the addons site.

Now I'm thinking I'll do what I did with the update checker - send the request to a page on the addons site just with the name of the addon as a querystring param - make it look for a matching add-on and redirect to that page if one is found - otherwise report that it couldn't be found.

linking the extension names in the "requirements line" as an anchor to that extension on that page (so the page jumps to it) would make it nice and easy to enable an extension that isn't.

Well, first of all, there are a few conundrums with some of the ideas in this discussion. Take the "automatic disabling" of add-ons that don't meet dependencies:

What if there are two extensions that depend on each other? You go to enable one, but it won't let you because the other isn't enabled. You go to enable the other, but it won't let you because the first isn't enabled.

After a good nights sleep to think things over, here's what I think I might do:

1. Add a new (optional) line to the default.php information section called "Dependencies".
2. If that add-on has dependencies, the line would appear like this:Dependencies: Yes
3. When rendering the extensions page in Vanilla, if the app encounters an add-on that has dependencies, it will ping to a page on the add-ons site looking up the dependencies for that add-on. It returns the names of dependent add-ons to the extensions page and they are rendered.
4. If those extensions aren't in the list of extensions in the forum, it won't allow that extension to be enabled - it will throw an error if you try to enable it telling you as much.
5. If those extensions ARE in the list of extensions in the forum, it will allow the extension to be enabled, but it will also enable those other extensions at the same time.

Dinoboff

(Since we will have to update default.php, maybe we could also add an optional add on ID field)