for f in $(find . -newer Vanilla-1.1.4.zip -name '*.zip'); do
zipinfo -1 $f | grep -q '\.DS_Store\|Thumbs.db\|__MACOSX' && print $f
done
./DirectMenuSignIn-2008-07-01.zip
./DefaultIcon-2008-04-18.zip
./Notify-2007-12-04.zip
./SubCategories-2007-08-30.zip
./the_beautiful_lie-2006-10-13.zip
./VanillaTeX-2007-03-17.zip
./Dizzy-2006-10-154.zip
./tonka-2006-09-28.zip
./PredefinedAttributes_v0.3.3-2006-07-03.zip
A couple of themes in there too.
I've just thought of another thing we should be recommending authors to do - minify their JS and CSS!
By default all extensions should ship with minified JS and CSS being loaded into the header, but they should also include their original, unminified source files for debugging and development. I suggest the following naming convention:javascript.min.js
javascript.js
stylesheet.min.css
stylesheet.css If other people agree with this, please could this be added to the first post in this thread? If not, I'd like to hear good reasons why not to do this - it will help keep Vanilla faster IMO.
For vanilla, the original and minified versions have the same names. The later replace the former when we are building Vanilla. Starting with Vanilla 1.1.5, you will find the originals files in the src folders.
It seems easier to do like that since for development you need to work with the original files and nobody wants to minify a file each time it is modified just for testing. A solution would be to parse php files to replace all '.js' by '.min.js' when creating the package or to have Vanilla using a setting to know which files to link in the header (the .js and .css files, or the .min.js. and .min.css one). But since on production, the original version is just there as a reference (if you need to patch the js file or if you are creating your own theme), I think the replacement is just fine.
I would prefer something similar for extensions: MyExtension/
- assets/
.htaccess
myscript.js
mystyle.css
- src/
myscript.js
mystyle.css
.htaccess
default.php
readme.txt
I guess both methods work fine, I suppose it doesn't matter how you do it, just that you provide minified files when you release - I guess that was my real point!
Out of interest, what are your .htaccess files for? Are they there to prevent people getting directly to the files in those directories? If so, what directives are you using in them?
For the structure I showed they would be: # MyExtension/.htaccess
Order Allow,Deny
Deny from All
# MyExtension/assets/.htaccess
Order Allow,Deny
Allow from All
If you have everything in the main folder, it would be: Order Allow,Deny
Deny from All
<Files ~ "\.(gif|jpe?g|png|js|css)$">
Order Allow,Deny
Allow from All
</Files>
I suppose this is good practice just in case someone has the permissions setup incorrectly on their webserver - might be worth suggesting this as a template for an example extension?
It is working with a white list. Only files with the following pattern will be added to the zip package: *.php
*.tpl
*.x?html?
.ht*
*.css
*.txt
README
INSTALL
*.js
*.png
*.ico
*.gif
*.jpe?g
*.xml
*.swf
*.sql
*.ini
*.mp3
*.gz
To build the extension you either use the command line: cd /path/to/extensions/MyExtension/
vf-manager build Or use a build script. #build.py
from vanillafriends.utils import Builder
Builder(
base_dir='./',
dist_name=None # Name of folder where this extension should be installed
# Use the extension name by default (Low-Cal Vanilla => LowCalVanilla)
).build() It will create a build and dist folder. "dist" will contain the packaged extension, "build" will contain what have been packaged.
It appears I've run into a problem while pulling my hair out to get the YUI Editor add on to work...
If you download the file from the vanilla add on page describing the file you just get an image file which is a screenshot of the editor in use... Evidently this is because actual editor file was larger than the lussomo server would allow for uploading, so he posted the real file on divshare.. This is not a big deal, but it would be nice if the info about this and the link were up there in the main description and additional instructions part of the page instead of buried n the discussions later on...
But beyond that minor stuff, is that when you unpack the file, the editor itself is in a folder called build and that is within the main folder called YUI Editor... But because of the following reason, I have not yet gotten the editor to show up in my extensions list, so I'm not sure if the nested folder thing is a no-no, but it seelms to me, that the build folder should not be there, and all the editor files should be directly in the YUI editor folder..
But the 'big' problem, is why it won;t appear in my extensions list, and that is because it has no default.php file in it's root directory...
I'm not php savvy, so I don't know if I can just copy one from another extension and use it or if it has to be custom... But he editor should include the default.php file in it when unpacked, with the proper folder structure... or at least a read me of some sort explaining how to create or get the default.php file and what not...
This may seem like an obvious fix to many of you, but for me, who is a novice at this stuff... It's a problem that has been pretty confusing..
Extension Name: Latest Topic
Extension Url: http://www.hotsnow.co.uk/Vanilla/downloads/LatestTopic.zip
Description: This extension will display the latest topic in the side panel
Version: 1.0
Author: Jamie Parkinson
... should be ...
Extension Name: Latest Discussions
Extension Url: http://www.hotsnow.co.uk/Vanilla/downloads/LatestTopic.zip
Description: This extension will display the latest topic in the side panel
Version: 1.1
Update check now works fine.
Comments
__MACOSXand.DS_Storefiles.By default all extensions should ship with minified JS and CSS being loaded into the header, but they should also include their original, unminified source files for debugging and development. I suggest the following naming convention:
javascript.min.js javascript.js stylesheet.min.css stylesheet.cssIf other people agree with this, please could this be added to the first post in this thread? If not, I'd like to hear good reasons why not to do this - it will help keep Vanilla faster IMO.
It seems easier to do like that since for development you need to work with the original files and nobody wants to minify a file each time it is modified just for testing. A solution would be to parse php files to replace all '.js' by '.min.js' when creating the package or to have Vanilla using a setting to know which files to link in the header (the .js and .css files, or the .min.js. and .min.css one). But since on production, the original version is just there as a reference (if you need to patch the js file or if you are creating your own theme), I think the replacement is just fine.
I would prefer something similar for extensions:
MyExtension/ - assets/ .htaccess myscript.js mystyle.css - src/ myscript.js mystyle.css .htaccess default.php readme.txtOut of interest, what are your .htaccess files for? Are they there to prevent people getting directly to the files in those directories? If so, what directives are you using in them?
# MyExtension/.htaccess Order Allow,Deny Deny from All # MyExtension/assets/.htaccess Order Allow,Deny Allow from AllIf you have everything in the main folder, it would be:
Order Allow,Deny Deny from All <Files ~ "\.(gif|jpe?g|png|js|css)$"> Order Allow,Deny Allow from All </Files>http://code.google.com/p/vanilla-friends/wiki/vfmanager
It is working with a white list. Only files with the following pattern will be added to the zip package:
*.php *.tpl *.x?html? .ht* *.css *.txt README INSTALL *.js *.png *.ico *.gif *.jpe?g *.xml *.swf *.sql *.ini *.mp3 *.gzTo build the extension you either use the command line:
cd /path/to/extensions/MyExtension/ vf-manager buildOr use a build script.
#build.py from vanillafriends.utils import Builder Builder( base_dir='./', dist_name=None # Name of folder where this extension should be installed # Use the extension name by default (Low-Cal Vanilla => LowCalVanilla) ).build()It will create a build and dist folder. "dist" will contain the packaged extension, "build" will contain what have been packaged.
Let me know what else you would like it to do.
If you download the file from the vanilla add on page describing the file you just get an image file which is a screenshot of the editor in use... Evidently this is because actual editor file was larger than the lussomo server would allow for uploading, so he posted the real file on divshare.. This is not a big deal, but it would be nice if the info about this and the link were up there in the main description and additional instructions part of the page instead of buried n the discussions later on...
But beyond that minor stuff, is that when you unpack the file, the editor itself is in a folder called build and that is within the main folder called YUI Editor... But because of the following reason, I have not yet gotten the editor to show up in my extensions list, so I'm not sure if the nested folder thing is a no-no, but it seelms to me, that the build folder should not be there, and all the editor files should be directly in the YUI editor folder..
But the 'big' problem, is why it won;t appear in my extensions list, and that is because it has no default.php file in it's root directory...
I'm not php savvy, so I don't know if I can just copy one from another extension and use it or if it has to be custom... But he editor should include the default.php file in it when unpacked, with the proper folder structure... or at least a read me of some sort explaining how to create or get the default.php file and what not...
This may seem like an obvious fix to many of you, but for me, who is a novice at this stuff... It's a problem that has been pretty confusing..
Thanks,
Mark