Not signed in (Sign In)
Categories
Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.
Help keep Vanilla free:Welcome Guest!
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.
-
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:- 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.
- extra folders in the folder structure (like /path/to/somebodys_forum/extensions/Addon)
- Fix: see #1 above
- extraneous files in the archive like Thumbs.db, .DS_STORE or __MACOSX
- Fix: there are several here
- 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
- 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
- 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.
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. - no folder structure in the add-on's zip or rar file (just a flat file list)
-
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.
-
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. -
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. -
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)
-
- CommentAuthorMinisweeper
- CommentTimeJul 9th 2007
We could make it a requirement that the extension folder is named the same as the extension? That kinda makes sense anyway.. -
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. -
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.
-
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
-
I may be misunderstanding point 2 - but are you saying we can't have /extensions/ExtensionName/js ?
-
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 -
Ahhhhhhhhhhhhhhhh - got ya ;)
-
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. -
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.
-
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.
-
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. -
oh yeah, i'm all over that. i'll email you later.
-
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? -
Link it to another page I reckon.
-
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? -
Yep, Vanilla already uses absolutes everywhere and the GetUrl function will always return an absolute. Best practice would be to use it.
-
I would like to rename my add-on David to StickyDavid (or something) to make it more meaningful and perhaps easier to find when looking for an add-on to do what it does. I also need to update it for the config settings update issue. So, what would be the easiest way to do this? I guess I could just add a new add-on with this name, but is there a way to obsolete the old David add-on?
-
- CommentAuthorMinisweeper
- CommentTimeJul 16th 2007
Just drop mark a line i guess... -
A question that could belong to this discussion: Where to put instructions. Do you prefer to have everything centralized in the readme.txt or do you think that what concerns a file should go in the comments of this file ? or even Both ?
Anyway, I think that configuration files should be pretty documented. -
Concise commenting in the code where (especially where you have options and settings) and an in depth ReadMe with included FAQ (this will grow from the discussion page of the addon). That gets my vote.
-
- CommentAuthorlittle_peet
- CommentTimeJul 16th 2007
[quote] * [-Stash-]
block userblock comment# 20
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?
[/quote]
Absolute url, is not the best way to go, in my believe.
first:
if you only use relative urls to the domain, all extentions will always work. It is impossible to add "fixed" absolute paths in an extention since the addon creator does not know on what domain the site will be. If the base url in the vanilla settings is set to / then all links will be relative.
second:
Relative urls is very easy scalable, and you can put a round-robin dns to serve multiple front-end webhosts to 1 database on 1 domain, or multiple sites like forum1.mydomain.com forum2.mydomain.com etc without the need to set up each server, just copy the settings and it will work. This also can be used for migrating from one server to another without downtime.
third:
A simple baseurl tag in the core will make all links absolute, no need to program it each time in every php line. This will make it less server intensive Each time the GetUrl is called the server is doing the job, better let the client do it.
Fourth:
Ever had a user complain he was logged in when he had logged out, logged out when he hits a link or a tab. This only occurs when you use absolute paths. On programmer has to forget the geturl in one place, and your users will run in to it, guaranteed.
Why not avoid the problem all to getter and don't use them, What isn't used can not be forgotten
Wow a lot of text for a small point, sorry for that -
Regarding your third point, this already happens for PHP I think, but it's not the case with JS or CSS (correct me if I'm wrong here people).
-
Relative URLs introduce a dependency on the directory structure of Vanilla. Calls to GetUrl don't1. I'm all in favor of relatives when it's the same directory or deeper, but using relatives to go up a level is just begging for trouble.
Edit #1: that is, not as much. :) -
Quite honestly, using relative paths going either up OR down through directories is just the same if not a little easier than stabbing around for a directory that doesn't exist under an absolute path. But that's all depending how you're use it in the first place. However, you could use both and string it together by calling the absolute base path from the config and building out the rest via the given relative which is probably the best practice if your installation and config is fairly standard.
-
For those fortunate enough to develop on a Mac...
Open terminal, cd to the directory you're going to tar up, and run this:
find . -name .DS_Store -ls -exec rm {} \;
Problem solved.
Although, I haven't heard anyone complain about them damn windoze Thunbs.db files, or damn dreamweaver _notes dir's... <cough cough> -
Easier still and much more user-friendly...
DS_Store Cleaner
Simply drag and drop the folder(s) onto it!
<cough cough> indeed!
Posted: Wednesday, 25 July 2007 at 10:08AM
-
- CommentAuthorMinisweeper
- CommentTimeJul 24th 2007
Thumbs.db annoys me quite a bit too. I've not used dreamweaver in donkeys years though. -
All annoying, but I've only personally come across .DS_Store rubbish from those fortunate* enough to develop on a mac...
* You related to Wanderer?
Disclaimer: I'm sure there are some addons with both the Windows thumbs.db and cross platform Dreamweaver _notes crap in them, I just haven't found any. -
Related only by having the same aptitude for selecting the superior platform and proud of it!
Posted: Thursday, 26 July 2007 at 7:11AM
-
I agree. They are all pretty annoying. But at least thumbs.db and _notes still allow you to extract the contents of a Zip file without any errors. That DS_store crap doesn't. Have to use WinRAR or go in the file and specifically select the files.
But they are all pretty annoying. -
here are a few:
Attachments: no readme
Delicious Bookmarks: contains a screenshot .gif
Discussion Pages: no readme
Discussion Tags: contains __MACOSX folder and .DS_STORE
MarkAllRead: does not have any folder structure inside the zip. files unzip directly into the extensions folder.
Nuggets: contains __MACOSX folder, .DS_STORE and no readme
Saved Searches: no readme (oops mark!)
Thankful People: no readme
UserInfo Tooltip: no readme -
Nuggets: contains __MACOSX folder, .DS_STORE and no readme
Since when does MySchizoBuddy develop on a Mac?
Posted: Monday, 6 August 2007 at 7:31AM
-
let's not start that argument again, ok?
-
Who's arguing mate?
I'm pretty sure MySchizoBuddy develops on Windows, if so how on earth did the __MACOSX folder, .DS_STORE files get there?Posted: Monday, 6 August 2007 at 9:16AM
-
settings/?PostBackAction=InlineImages
In the panel you'll notice two headings, Options and Extension Options. Please can all extensions put their options/settings in the latter (Extension Options)? When everything just gets dumped in the the "Options" list it just makes it harder to navigate the standard Vanilla options. Also, having the link say "settings" is a little overkill once it's under the "Extension Options" heading.
I suggest that a future release of Vanilla actually makes it impossible to add things to the "Options" list and keep it as a core settings area only. In the mean time, here's a brief list of extensions that put their settings in the "wrong place":
Account Pictures 1.1 - "Account Pictures Settings" <- redundant "settings"
Page Management - different name from the extension
Announcement 1.2 - redundant "settings"
Custom Styles 2.1 - different name from the extension "Style Definitions"
Forum Statistics 0.4.5
Friends 1.7 - redundant "settings"
/me got bored here...
Attachments, Packer and Contact Form also have the redundant "settings" although they are in the correct place. -
::Adds guideline to the Wiki::
-
Vanilla-New-Applicants-2007-09-09.zip – Contains "__MACOSX" folder
SubCategories-2007-08-30.zip – Contains "__MACOSX" folder
MembersOnly-2007-10-14.zip – Contains "__MACOSX" folder and .DS_Store file
JQSmoothJump-2007-09-04.zip – Contains "__MACOSX" folder and .DS_Store file
DiscussionExpiration-2007-10-26.zip – Contains "__MACOSX" folder and multiple .DS_Store files
FeedPublisher-2007-10-31.zip – Contains .svn folders
LightGallery.0.0.1-2007-09-09.zip – doesn't wrap the files in a single folder
YUIEditor-2007-11-12.zip – doesn't wrap the files in a single folder and appears to just be a GIF... -
No shame in using Mac OS X mate, name and congratulate I say! :-)
...hmmm, Note to self: must check out my uploaded packages... -
SHAME on me, I'll remove them in the next FP release, that should come soon...
-
svn export is a handy command. :)
-
1. I think there might be an example/dummy add-on, so everybody can download it and use it as a starting point
should maybe contain:default.php
readme.txt
conf/database.php
conf/definitions.php
conf/settings.php
library/ (Classes and libraries)
translations/ (here should be put LANGUAGE.php files)
All the files will contain only includes of the files (including ./conf/definitions.php, ... in default.php) and commented text guiding a developer where it is ok, to put the code and what kind of code.
I can create such dummy add-on also for language add-ons. Depends if we can all agree on some skeleton.
btw, I actually made an extension ExtensionLanguageLoader which tries to read language translations from (not mentioning some others places not important to explain here):
languages/LANGUAGE/extensions/*.php and also
extensions/*/translations/LANGUAGE.php
I would like it to be the standard of placing extension translations since there is none really working system for this yet (using conf/language.php is useless because it doesn't allow use multiple languages - for example with LanguageSelector).
2. There is a lot of add-ons using old way of defining language dictionary definitions:$Context->Dictionary["word"] = 'definition';
should be:$Context->SetDefinition('word', 'definition');
This make extension translations to be always overdefined by default language definitions.
I made a bash script and made it an extension FixLanguageDefinitions which goes through all installed default.php files and it fixes these definitions, but it would be really much better if extension developers would fix these definitions themselves so this script would not be needed at all.
I can make a list of such addons if requested :)
@ithcy: any progress with the extension allowing to download? I would like to use that! :-) If there is a problem with wrongly released add-ons, you can just not allow to install the add-on, but I would really like to use it :) -
Hi Klip, could you please detail the purpose of conf/definitions.php and conf/database.php ?
-
conf/definitions.php containing language definitions:
<?
// use this file for dictionary default definitions
$Context->SetDefinition( 'term', 'definition' );
?>
conf/database.php containing extension database tables settings:<?
// use this file to define your database tables
$Context->DatabaseTables['MyExtensionTable'] = 'MyExtensionTable';
$Context->DatabaseColumns['MyExtensionTable']['MyID'] = 'MyID';
$Context->DatabaseColumns['MyExtensionTable']['Caption'] = 'Caption';
?> -
I cannot move the categories up and down when i have 'notify' installed
-
Please post in the Notify addon discussion or start a new one.