Remove .org required folder structure

[DevinVinson]

I think the benefit of having the folder structure pre-setup for .org submission is no longer as important as being able to quickly generate a copy of the repo right into a project and start working on the plugin.

I'm looking for some feedback but without the plugin-name>trunk>plugin content structure you would be able to do a quick git clone right into your local plugin folder or include it in an automated build a lot easier.

Perhaps the simple answer would be to make a new repo for a boilerplate .org submission folder setup with the plugin boilerplate as a submodule.

[jjeaton]

:+1: to both.

[slushman]

Agreed.

[dmtrmrv]

I agree too.

[AlchemyUnited]

can i add something?

if i had 3 Wishes one would be to institute some sort of standard on anything - plugin or theme - that comes off .org. trying to deconstruct (?) some of that stuff can be time consuming, unnerving, etc.

point being, perhaps a submodule is gonna add friction to that process such that this won't get used at all?

put another way, a standard isn't a standard if there's more than one way to do it ;) why can't they both be exactly the same? where the code comes from shouldn't matter, should it?

or am i missing something here? sorry?

[DevinVinson]

@AlchemyUnited - This would do nothing to the internal structure of the plugin or how any end user would receive it from the WordPress.org repo. It would only change how we utilize the boilerplate when creating plugins.

Instead of starting off as if the plugin was about to be submitted to the svn repo, you would be starting off with the file structure of the plugin itself.

That is also a lot easier to document than symlinking or other hackery :smile:

[mAAdhaTTah]

@DevinVinson I flattened the structure in my fork. I don't think this structure is necessary, personally, and makes things a bit more complicated, you can't just clone the repo into your plugins folder and start working on a new plugin. There's all this symlinking and whatnot that has to go on before it works. If this is supposed to be an easy introduction to plugin development, I think the folder structure makes it more complicated.

[DevinVinson]

I agree @mAAdhaTTah . That is the point of what I am proposing; remove the need for symlinking and allow for the boilerplate to be cloned directly into your plugins folder.

[mAAdhaTTah]

If it's helpful, that fork also has a deployment script I use. Not all of it necessary, because of the tooling I use, but it might be useful to you to add when you flatten this structure. A simple shell script would be easier to use than submodules, I think.

[AlchemyUnited]

@DevinVinson - thanks. I promise to finish my coffee and read deeper next time.

p.s. do you think it would help to have folders for pre gulp / grunt and then post? as opposed to different ppl doing things slightly different for no real reason other than that's how they do it?

[DevinVinson]

@AlchemyUnited - If anything I would probably include grunt since that is what core uses.

I started/created the new repo for this here: https://github.com/DevinVinson/Plugin-Directory-Boilerplate

[DevinVinson]

I had been still partially on the fence about this one because it will change so many tutorials but with things like this popping up I'm going forward with it: http://wptavern.com/ship-a-new-app-for-shipping-plugins-from-github-to-wordpress-org

[grantpalin]

I agree, the extra depth makes getting started a little more complex. Then again, I put plugins I am working on elsewhere and symlink (on Windows: mklink /D) the trunk folder into my local site plugin folder. But still, less is more in this case.