Agree on recommended organization for static assets and convert plugins to use it

[ewinslow]

Goal is to add clarity to plugin structure by standardizing on a naming convention. We are doing pretty well with js/* for scripts, but images seem to have no solid convention right now. I've seen _graphics, images, graphics, static/images, etc.

This problem also exists with other static assets that have no official folder: fonts, flash, etc... Should we consolidate these things under a single, top-level "static" or "assets" folder?

[ewinslow]

Oh, and if we do this, it could lend itself to view-like overriding so that /static/my/flash/resource.swf actually points to the last loaded plugin to define that resource in its static folder.

And then we can turn off static access to /mod/, which I know we all want.

[krienas]

voting up for this to be solved.

[krienas]

And sharing with you list of plugins with possible troubles. Thats what I managed to find so far. Do not believe it is final.

Plugin name	Suspicious code locations	Resources called directly
Profile	​1	Direct call to icondirect.php
Bookmarks	​1, ​2	graphics/bookmark.gif
File	​1, ​2	thumbnail.php, graphics/icons/xxxx.gif
Groups	​1	graphics/defaultxxx.gif
Notifications	​1, ​2, ​3, ​4	graphics/xxx.gif
Pages	​1, ​2	images/xxx.gif
Reported Content	​1	graphics/icon_reportthis.gif
tinymce	​1	Suspicious line related to CSS. It is possible that CSS infrastructure is not used.
twitter	​1	graphics/twitter16px.png
twitter_api	​1	graphics/sign-in-with-twitter-d.png
zaudio	​1, ​2	audioplayer/player.swf, mod/file/download.php

[krienas]

one more location:

Plugin name	Suspicious code locations	Resources called directly
Developers	​1	engine/tests/suite.php

[sembrestels]

I think we shouldn't merge static content, like image.png, with dynamic content, like thumbnail.php.

For static contents, I agree in add them all into /static folder. We should rename _graphics core folder to make it consistent.

For dynamic contents that we don't want to load whole core to render, like thumbnails, icons... maybe we can create a new handler: engine/handlers/image.php? Maybe something more generic, like nocore.php...

[krienas]

Yeah, I totaly agree that static resources should not be merged with dynamic.

Here is what I had made so far. As there was statement in elgg documentation best practices that there should be no need for direct access of elgg files, I had moved document root to <elgg_root>/public (similar way as ZF and other frameworks do) and now I see issues related to this move. Above comments have a list of issues I already encountered + locations following the same pattern where I think may be problems, just not tested properly. Some of these I have fixed already.

Approach I used to solve:

• dynamic content/scripts - modified them to use page_handler or action_handler functionality. I have a feeling that plugins already have everything what is needed to solve this issue, just need to adapt and use it and there is no need for additional solutions. Additional solution could be handy to keep backwards compatibility according to release policy. But is it really an issue?
• graphics folder - At the moment I have only this one solved. Had created new handler by using page handler as code base. Now I route all calls to /<plugin>/graphics/<something> through that handler in the same manner as elgg does for page and action handling. When plugins are being loaded, if there is graphics subdirectory in plugin's directory, default graphics handler is registered automatically. It can be overridden by plugin by using elgg_register_graphics_handler(..). Default implementation sets mime type and outputs content of requested file to client. There is no caching atm, simply not familiar with this yet. Solution is quite general, works well with folder structure within graphics and I think after minimal tweak it could work for all static content.

So basically with this we already cover absolute most of issues. TinyMCE issue remains not inspected + my solution is not tested with flash and other more popular file types. If you want it, I may create pull request within days.

[sembrestels]

Don't worry about TinyMCE. We use CKEditor in 1.9.