Laying them out as they exist in the CMS isn't an option, unless you want to create a hella-complicated build script to handle it.

The layout here is the typical setup for a joomla package that includes plugins, modules and components.

The build script I'm using isn't that complicated - it simply groups the files together in their filesets - which is pretty much what you're gonna be doing anyway https://github.com/JoomJunk/Accordion/blob/development/build/build.xml#L114

For single extensions, that isn't so bad. But as @dongilbert said, it isn't that practical when you have several extensions in a single repo. I've done the overly complicated build scripts in the past, it's just excess effort for the sake of someone's convenience.

Well in my opinion to get as many people as possible contributing to this still we need to make it as easy as possible for people to contribute and leave the effort to us for the build script

Well in my opinion to get as many people as possible contributing to this still we need to make it as easy as possible for people to contribute and leave the effort to us for the build script

I think that is an important consideration

How is it not easy to contribute with the file structure as is? It's organized in a logical manner and each item is easy to find, without excess folders in the filesystem.

For reference, the patch tester uses the "standard Joomla filestructure" and a shell script for packaging - https://github.com/joomla-extensions/patchtester/blob/master/build/patchtester/build.sh

That's a lot of copying and moving for the sake of having the repo code organized a certain way. Multiply that by the number of extensions in the weblinks package. Then convert it to Phing.

Is it not possible for people to learn and grow in their understanding of how things are done? I'd rather do it the correct / accepted way and offer education to help people move onwards and upwards.

This is the exact same principle I applied to the Platform which became the Framework. Sure, we didn't need namespaces and everything, but it's the correct / accepted way to write your code, and doing so while offering some education on the subject helps people improve.

I don't mean to sound like a dick here, but if someone can't be bothered to learn the differences in file structure between an in-development extension and an installed extension, I'm not 100% sure we would want their contributions.

I use a similar file structure like this here and without any build script (I'm to lazy to learn that stuff).
What I do is that I just right click on the folder and zip it. And install/update the extension on my server using the Joomla installer.
Yes, I can't directly have my git repo in the server structure. But my server isn't a local host anyway, and thus Git is slow as hell there. It's faster for me to just install the zip and I even have tested install/update doing this

Question: Will these files be moved into current Joomla locations? Or, will the files/folders install into the Vendor folder? (And changes made to core to locate the extensions?)

In the past, we've encouraged a process of using a repo that resembles the distro in order to make it easier to develop. That way, a developer can work on their extensions in the location those files will reside and use a gitignore containing a list of core files to ensure those files are not committed to the extension repo.

I think I disagree with you @dongilbert that there is an accepted way for how extensions are handled by applications. The approach here is one for packages shared on Packagist that are useful in any PHP application. Extensions are a different animal and vary from application to application. Not so sure those should be on Packagist, anyway.

To me, it's a question of how extensions will be installed -- and how best to support developers in their development/distribute process (and make it easy for others to make PR's on their work.) I've not seen any really good setups on this yet.

It's ok for you to disagree @AmyStephen, we can still be friends. I think you're mixing some things up though because of George's comment of "I know this is the 'PHP' way of doing things". Let me try to clarify.

The "correct / accepted" way I referred to is not in reference to applications handling extensions or about throwing code in a src/ folder like I would for distributing a library via Packagist. I'm referring to how Joomla extension developers normally structure their folders for Joomla development.

Also, these will not be put in a vendor location. They are Joomla Extensions and will be installed just like any other Joomla Extension in their corresponding location.

That could be - can't really speak for others - but I've personally not structured my extensions in this way.

What's the possibility of using namespaces for these extensions and installing in vendor? If that would be possible, this approach wouldn't require symlinking or complex build processes. The distribution repo could mirror the package closely.

Ok. I had to say it

My prefered structure:

component
-- admin
-- site

libraries
-- lib_whatever

media
-- foobar

modules
-- admin
----- mod_foobar
-- site
----- mod_barfoo

plugins
-- system
---- foobar
-- content
---- barfoo

templates
-- site
---- tpl_foobar
-- admin 
---- tpl_barfoo

manifest.xml
install.php

The key to me:

• You can fastly see where is everything
• Zip & install directly from Github
• Easy to test installer (install from folder works directly)
• I have a build to deploy it to test discover install
• I have a build to symlink it to a working site
• I can share the structure + build scripts on all my extensions

Sorry @mbabker

OK so apparently there is no "accepted way" even amongst Joomla developers on the PLT! lol

@AmyStephen Namespaces without aliases to the old class names won't be introduced before 4.0, at the earliest. As for distributing via packagist, we already have the JED and install from web, so I don't see that changing in the 3.x series either. Great ideas though! They'll just take a while before we can implement.

Yea, it will take awhile to get there. Would be nice to have an in-between state where you could have extensions using namespacing. With PSR-4, really doesn't matter where those files sit and getting rid of build scripts and symlinking would be nice. (Not recommending Packagist, tho - still think it doesn't belong there but using Composer to handle the install would be cool.)

Good stuff -- keep moving forward!

I'm with @wilsonge here. Having the structure directly in root simplifies a lot (automatically built new releases compatible with Joomla! updater, simplicity). You just have to set the .gitignore rules for files/ folders you want to exclude from releases, see example.
Adding new release comes down updating update server (gitignored part of repo) and creating a new tag and. I'm sure there's event a way to use download bleeding-edge version of extension directly from master branch.

Current structure reminds me of composer package but we are not there yet.

@phproberto's option looks like the best option for me :)

I've arranged the repo this way "for now" because a) I cheated of one of Michael's repo's, and b) it allows for the most simple build script. However, I'm not sure I like it myself or whether it is the best option. The major drawback to this approach is soft linking from the repo to a CMS install is more difficult than with other types of structures.

I encourage everyone to try different arrangements and different build scripts. The best we can hope for is probably having three or four options out of which to make a final selection. I'll certainly be trying a "native" folder layout myself and seeing how that affects the build script. The only thing I would encourage is that we keep the /src/ folder so that the root is free to hold /tests and /docs.

Might be nice if you could pass in a path to JComponentHelper::renderComponent($component), etc. Then, you might be able to start moving folders around and create a package that mirrors the repo.

@AmyStephen that a good idea but I think it would be best to keep the first version as close to native as possible. A new extension paradigm is something I'd love to work on but getting this first step out of the way is important (and fun). If successful, a number of other extensions will move out in Joomla 3.5.

A new extension paradigm would be a huge step and not something I'd look at now. Was just trying to think of "easy" ways to address the problem George raised about mirroring the repo structure. I'll try to turn my thoughts on this off. =)

Hehe. The main problem to solve here is how to best balance easy-to-build with easy-to-maintain and customise.

I think the current structure is best compromise between Current extension structure and readability. I'd just rename the manifest.xml to updates.xml. Manifest reminds me extension manifest file, manifest_cache name is used in #__extensions table.

I'd also add the /schema folder with table definitions in abstract format such like Docrine's simplifiedYaml format. We don't have to use ORM to build tables for different database languages, but such schema is much more readable than built sql files. Example: Extension.orm.yml

I'd also add the /schema folder

Maybe we can work on that when 3.4 and Weblinks 3.0.0 is released? Remember we also have database XML export and import classes in the Database package in the CMS.

@eddieajau okay, it's a secondary issue.
As far as I know contributors are updating database scripts manually for all the 'supported' languages so this could help to see how the tables look like without inspecting the code

Output of the DatabaseExporter seems to be coupled to database language and it's not much clearer than the structure itself, using $db->getTableCreate

https://github.com/nonumber/benchmark
https://github.com/joomla-projects/com_localise

Just to show some other people doing it the way I was suggesting :P

If you want something bad enough you can find what you need to support it
:-P

On Tuesday, April 15, 2014, George Wilson notifications@github.com wrote:

https://github.com/nonumber/benchmark
https://github.com/joomla-projects/com_localise

Just to show some other people doing it the way I was suggesting :P

—
Reply to this email directly or view it on GitHub#8 (comment)
.

:D

Just to show some other people doing it the way I was suggesting :P

I've done it that way as well, but the build file it a bit more complicated when you do it that way. I just haven't had time to devise an elegant way to do that. I'm still a big fan of including a root /src/ folder though. And I think we are going to end up collecting the language files into one place anyway so I don't know that we are going to get a 1-to-1 mapping long term.

The ideal is to invent a new extension format where you just drop everything into one folder on the site. I don't know we have time to explore is, but it would be interesting to ponder. Maybe something like:

cms-root
|- administrator
|- ...
|- packages
   `- weblinks (all executable code for the components, modules, etc)
|- language
   `- weblinks
       `- eb-GB
|- media
   `- weblinks (web media)
|- ...

That makes your extension repo drop dead easy to configure. That would make future service locators really easy to work with as well.

Thoughts?

No activity for a while. Closing issue. Suggest the next step is a pull request if there is any interest in doing something different than what is already proposed.