aubreypwd / wpkickstart Goto Github PK

Because I've been working with https://github.com/WebDevStudios/oops-wp a lot more I think I would be more inclined to probably use that to spin up new things going forward, or at least take a more holistic approach...

So because of my recent developments with that, and our official use of it at WebDevStudios, I may be closing wpkickstart out!

The includes/ folder in this structure really only have to do with the App now. We need to also make this backwards compatible a bit, so that we still load includes (enhance autoloader more lol).

Right now all composer packages are installed in /vendor. But features can have their own composer package dependancies and those don't need to go in /vendor at the root. E.g.:

In this example one of the features has it's own composer dependances.

Let's make sure the root composer.json also installs those by looping through the folders looking for composer.json and running pre/post install/update commands in those folders too.

https://github.com/aubreypwd/wp-plugin-boilerplate/blob/master/plugin-name.php#L24

Putting $app out in the global space does in fact make it global (not to the namespace). What that ends up doing is colliding with other plugins built on this structure. It needs to go in a static variable in the app() function. Or, it needs to be unique.

• Add $app as static var in app()
• Document how to make it global, but how to make it unique

The second task above is so that you can use the below method to get to the app object:

global $app;
$app->thing->action();

Classes in features/ should have a run method. The App class should run these automatically when they are attached to the base app.

I think this would just be a sub-module for the wiki?

Idea 1

• Move all documentation to wiki
• Maybe (if we can) make wiki composer installable
• Commit the docs to the repo if we can
• Add documentation to update docs with composer update

With 2.2.0 and all the things we've done tests may not be working, let's beef those up!

class-app.php#L112

Here, if you create a class like, Edit_Posts you have to create a file like class-edit_posts.php which should be class-edit-posts.php.

$file = 'class-' . strtolower( str_replace( '_', '-', end( $parts ) ) ) . '.php';

...is better.

Right now we load a component library, let's work on making components individually installable. But also make the wpkickstart-components just be an easy JSON library of where they are?

I don't know if cli does an interactive mode, but would be cool to install the plugin, activate it (as is), and run wp kickstart and it start asking you for replacements to make.

• Add the cli command
• Update documentation
• Remove old replace.php method

This was an idea given to me by a coworker, e.g.:

• feature-name/
  • assets/
    • js/
    • css/
  • class-feature-name.php
  • vendor/

The idea is that the folder feature-name could be moved around to other plugins using this same platform. E.g. bug-spray could be easily added to another project just by copying the folder (which has all it's things) to the plugin on another projects and loaded into the class-app.php and run it's hooks/etc.

Maybe hooks could be auto loaded now which would do all the things.

On a call today with @jrfoell and @efuller they said they'd like to see what this would look like if it used a standards PSR4-ish autoloader.

I, simply, should be able to write SASS. And when I save it a .css version of it is made so I can enque it.

Writing ES6 takes a great deal of work to get it to work in ES5 browers, etc. I know there are ways to write ES6 code and transpile it down to ES5 for other browsers. Let's make it really easy to write ES6 yet enqueue ES5 versions of it.

Details to come after I get a solution in place, but basically in constructs calling app() gets a max-depth issue.

The way you are supposed to build features/components out is that each component should work somewhat independent of one another. Pulling in another component into another creates a dependencies between the two.

So the way I've been doing it is that there is always a conductor of sorts that connects all the components together and is usually the base feature class that does it, and this is usually what builds out the main feature of the component....

E.g. in a component called example it's class-example.php that does the conducting and uses the various other components creating a dependency with most other components.

All this said, I'd like a way to identify it as so somehow. Idea(s):

• You create a component called components/conductor/class-conductor.php

The attachment would look like:

new Conductor()

This doesn't make sense actually because you could have many conductors, maybe we do:

• You have both components/ and features/ folders. features/ do the conducting (maybe name conductors/?) and use the components/ which have less dependencies.

I LIKE THIS!

Will have impact on #7

Why make the user attach a service, we can auto-attach these.

The autoloader needs to be even smarter.

If I make a e.g. new Class() that isn't attached to App I should be able to do it. Only detected feature classes and detected includes (which usually only have to do with the app infrastructure) are autoloaded from App.