Add-ons name and shame

ithcy

if you find an add-on that does not conform to standards, please post it in this thread along with a description of what's wrong so the author can fix it easily.

violations include:

1. no folder structure in the add-on's zip or rar file (just a flat file list)
   • Fix: the archive should contain the folder (yes, the folder itself) which holds the extension files, its contents, and nothing more or less. please check the contents of your archive before you upload it.
2. extra folders in the folder structure (like /path/to/somebodys_forum/extensions/Addon)
   • Fix: see #1 above
3. extraneous files in the archive like Thumbs.db, .DS_STORE or __MACOSX
   • Fix: there are several here
4. the add-on name in default.php does not match the one at lussumo.com/addons, so vanilla's update check feature doesn't find the addon
   • Fix: check the "official" add-on name at lussumo.com/addons, and change line 2 in default.php (the one that starts with Extension Name:) to match the official name exactly
5. the version number in default.php does not match the one at lussumo.com/addons
   • Fix: as above, but change the line that starts with Version:) instead
6. installation instructions are missing or confusing enough that they might as well be missing

• Fix: this is a good start, but PLEASE write some good instructions. if you have poor english, you're sure to find someone who is willing to help here in the lussumo forums.

Incorrect language string configuration

• Fix: Change to using $Context->SetDefinition - see here

i have seen all of these too many times. (i've been guilty of some myself.)

i am working on a very cool extension that i think a lot of people will like, but my life and yours are hampered by these vicious rogue add-on authors. maybe this thread will put a little pressure on people to clean up their stuff.

marikka

Most of these could be easily checked by the script receiving the add-ons in the first place. I know it's the developers' responsibility to adhere to the rules in the first place, but most of the time a rule is only useful if correctly enforced.

ithcy

some of them could be checked. but how can a script tell if you write terrible documentation?

also, how can it tell when you've included the path all the way from root in your zipfile? (maybe your extension really is called var and has subfolders called www/htdocs/myforum/extensions/MyExtension/)

likewise, how can a script tell when you didn't include the containing folder for your extension, especially when your extension may have arbitrary subfolders inside it?

these are not "hard rules", they're just guidelines. it really is up to the developers to not make things difficult for other people.

marikka

You could determine if the path structure is correct by locating the default.php file and counting from there. In your example it could be determined that MyExtension is the extensions folder (because it has default.php in it), and the rest (extensions, myforum.. ) would cause an error. The same goes for the "containing folder" problem.

ithcy

there is no rule against having multiple default.phps in whatever subfolders you like. (which means it's not possible to check for a single default.php and count from there)

Minisweeper

We could make it a requirement that the extension folder is named the same as the extension? That kinda makes sense anyway..

ithcy

i would totally have it that way, yes.

actually maybe extensions should have a "name" and then a "verbose name", because i think people want to have names for their extensions that wouldn't work as folder names.

"real name" is the folder name
"verbose name" is what shows up in your vanilla add-ons page and on the lussumo site.

ithcy

in case you think i'm being argumentative, marikka, i'm really not. i've been trying to develop a meta-extension that downloads add-ons from lussumo and installs them automatically (a capability which i think is sorely missing from vanilla), so i've run into these problems over and over again recently. i've tried every way you can think of to get around these issues programmatically, including both of your suggestions. they do not work. no script will work unless people follow the guidelines.

Wanderer

Quote: ithcy
no script will work unless people follow the guidelines.

...and that my friend, is an under-statement. It is and has been the bane of all programmers and coders since the beginning of time!

Which is why good coders (and administrators and parents and educators) always incorporate fail-safe mechanisms which, although they cannot always "fix" the non-compliance, will highlight it as a problem or issue.

If you want to name-and-shame effectively, get your script to throw up an alert when the required conditions are not met. (Then, either crash the browser (kidding) or exit as gracefully as the situation allows.)

Posted: Tuesday, 10 July 2007 at 8:42AM

Stash

I may be misunderstanding point 2 - but are you saying we can't have /extensions/ExtensionName/js ?

ithcy

no, not at all. i mean don't include the full path in the archive.

okay:
ExtensionName/js/whatever

not okay:
/var/www/htdocs/mywebsite/forum/extensions/ExtensionName/js/whatever

Stash

Ahhhhhhhhhhhhhhhh - got ya

Grahack

Hi there, nice topic.
1) Would it be ok to have 'Feed Publisher' as the extension name, 'FeedPublisher' as the folder/.zip name and 'Feed Publisher' in the default.php file? My bad, I have 'Feed Publisher' as the extension name, 'FeedPublisher' as the folder/zip name and 'FeedPublisher' in the default.php.
2) Your guidelines should be listed on this page. What do you think?
3) Not sure about the way to make progress on the global rules following. This topic is a good first step, where we can give ideas about how we could proceed. But 'please post it in this thread along with a description of what's wrong so the author can fix it easily' is useless I think.

What I personaly think we should do if we encounter a problem:
a) try to notify the creator in private, then one or two weeks later, if no update
b) post in a relevant discussion (I mean not the one you're reading but an 'add-on discussion'),
c) and I think that it's all that can be done. Throwing shame on the extension won't be of any use, especially in a post that isn't read by everyone. Or maybe a page in the wiki with big red and flashing letters...

EDIT: if Mark agrees, we could even replace this old page with the general addon guidelines + ithcy's ones.

skube

What about coding standards? Like extensions that load all their dependencies (styles, js, etc.) on each and page load needlessly. It's obscene! Also, using language definitions properly. Or using the framework properly. I think there could definitely be some better documentation.

Stash

Come on then skube, list some then. Perhaps you can give some pointers as to how to improve these points so advice can be added to the wiki.

Mark

I'm all for it if you guys want to take on better documentation on the wiki (that's why I made it a wiki .

I'd even be interested in letting ithcy at the addons site code if he wanted to write some code to open up the zip and make sure that the guidelines were followed properly. Ithcy - you know my email if you're interested in this.

ithcy

oh yeah, i'm all over that. i'll email you later.

Grahack

I worked on the extension page (see the diff). I just listed the pages describing Vanilla's internals and ithcy's guidelines.
I don't know if the Wanted Extensions section is up to date, I guess not. Anyone that can update it could be of great help. Maybe this list could be moved to its own page, what do you guys think?

Stash

Link it to another page I reckon.

Stash

Extensions don't respect base URL # 5
Relative and absolute URLs... what's best practice? I would think that absolute URLs using WEB_ROOT and the like would be best no?

WallPhone

Yep, Vanilla already uses absolutes everywhere and the GetUrl function will always return an absolute. Best practice would be to use it.