Different project vision?

[obstschale]

Hi,

thank you first off all for inviting me as collaborator. I appreciate that. As you already saw I forked the project and worked on some own ideas. The reason why I did not send a pull request is, I have the feeling we have different ideas how things should be built. I don't say my style is better than your's but different. So before I join forces, I would like to see how this thing might work out.

My Idea / Vision

I would like to build nice boilerplate plugin, which implements current best practices (from the PHP world not only WordPress) and is ready to run and has some example code already on board. But I guess this not the main issue because your repo already goes in that direction :+1:

Design Decisions

The things that keep me thinking are different design decisions. Based on my last issues, I conclude we do things differently. And so I would like hear what you think about some ideas I implemented on my fork.

1. I added a more granular project structure with more directories (PostTypes/, Shortcodes/, 'Widgets/`)
2. One files holds only one class (see WdigetLoader and ExampleWidget)
3. I added a ShortcodeLoader according to WidgetLoader. And to make things more OOP I also added an interface ShortcodeInterface to make sure every shortcodes follows the some structure
4. I use webpack with Laravel Mix as wrapper
5. I like to separate compiled files from assets. I renamed assets/ to resources/ and all compiled files are placed in public/. (This is how Laravel does it)
6. I will use WPUpdatePHP
7. I require PHP 5.6+, because this is the oldes but supported php version. Although I code in PHP 7 most of the times
8. Your idea with the $settings variable in Plugin is nice, but I would go a step further an decouple that from that class and introduce a registry.

These are the things I changed so far. What do you think?

[dmhendricks]

The reason why I did not send a pull request is, I have the feeling we have different ideas how things should be built. I don't say my style is better than your's but different.

Agree. After inviting you, I looked at your gear more closely and see that it is/will become quite different. I left the request in case you wanted it for some reason.

That said, I really like a lot of what you're doing and will copy it over (giving you credit, of course) when I have time.

I would like to build nice boilerplate plugin, which implements current best practices (from the PHP world not only WordPress) and is ready to run and has some example code already on board.

I agree except for one minor/possible thing - I, personally, would probably learn towards WordPress conventions, in general (such as function/class naming, et al) because it will only be used by WordPress developers and I like consistency.

1. I added a more granular project structure with more directories
2. One files holds only one class (see WdigetLoader and ExampleWidget)
3. I added a ShortcodeLoader according to WidgetLoader.

I saw this, I like them, and I want to do this in my own (giving you credit, of course).

4. I use webpack with Laravel Mix as wrapper

I love this, too, and had been planning on adding Gulp eventually (It is what I'm used to and what I use on my own plugins). I'd prefer webpack as long as I could get the features I want and that they worked roughly as well. Sadly, I am not a webpack expert and my time is limited.

5. I like to separate compiled files from assets. I renamed assets/ to resources/ and all compiled files are placed in public/. (This is how Laravel does it)

This makes sense. My only nitpick might be that /assets rather than /public is more "The WordPress way" (and I think wordpress.org repo looks for screenshots in /assets now?)

I was wondering if, instead of creating separate /resource & /public directories if it would be more ubiquitous to have src/ and dist/ subdirectories of wither assets (or in your plugin, resources probably)?? I'm still pondering this one, which will matter more when I eventually throw in a task runner (which also requires me to choose one first! I know gulp, but I also know that people consider it for old folks).

6. I will use WPUpdatePHP

I am curious what this extra dependency/file size adds that a few lines of PHP (version_compare, phpversion() and admin_notice) does not. I haven't figured that out yet, but feel free to share.

7. I require PHP 5.6+, because this is the oldes but supported php version. Although I code in PHP 7 most of the times

I agree, am aware, and constantly complain to clients to upgrade to 7 (if for no other reason than the speed bump, but they usually refuse). That said, My goal is/was maximum compatibility for maximum appeal.

You'll noticed that I already bumped to 5.4 because although I fixed the short array() syntax issue (plus one other exception with my use of debug_backtrace() in 5.3), any Composer dependencies that I use that do not will fail. To avoid headaches, I increased it to 5.4 (though it will still work in 5.3 if your dependencies are compliant). I may increase it further in the future as I run into other irritations.

I'd much prefer 5.6 as a minimum (and even that I'm not thrilled with) as it is the minimum that I require for things that I suppose professionally. However as mentioned, I was targeting widespread usefulness. I develop most of my stuff in PHP 7 (some in 5.6 yet depending client environment, and in rare cases 7.1 if everything plays nice).

8. Your idea with the $settings variable in Plugin is nice, but I would go a step further an decouple that from that class and introduce a registry.

Agree!

Thank you for the long write up! It gives me many things to think about. I have a lot of features that I want to add (my code is getting somewhat outdated), but I haven't had time to merge them in from my own tools yet. So little time. :)

Anyway, it's fine if we have separate repos (that's what GitHub excels at!). If you add something that I like, I will just copy it over (with credit).

Please feel free to continue to challenge my brain with your ideas. I like all of them and agree with most of them.

[obstschale]

I read your comment several times to figure out where we differ. Because I still think it would be nice to have one base-plugin to reduce the work. I see we have a lot in common and can benefit from each other. There are only a couple of issues we would need to talk about. And these are:

• WPUpdatePHP -vs- self-written logic
• grulp -vs- webpack

With issue about assets/ or resources/ is not that important for me. I just followed a more Laravel approach, but I understand your point, that it is still a WordPress plugin and a more WordPress'isch style could be beneficial.

I, personally, would probably learn towards WordPress conventions, in general (such as function/class naming, et al) because it will only be used by WordPress developers and I like consistency.

I'm not sure what you mean with "function/class naming". If you mean code style I would prefer sticking with PSR-4, because that was one reason I forked this repo.

I'd much prefer 5.6 as a minimum (and even that I'm not thrilled with) as it is the minimum that I require for things that I suppose professionally.

I'm not sure if I understand you correct here. Do you mean, you would like to require 5.6+ but you stick with 5.4+ to make it available for a larger group? I think requiring 5.6+ should be ok for me. Every project I'm working on is running at least 5.6. If I found a client with <5.6 I talk to them. But my goal is always to code with PHP 7+, like you.

So what I want to say: I would like to make the required version 5.6 (or even 7 if possible), but I could also live with 5.4, because in the end it is "only" the boilerplate which is PHP 5.4. My own logic can be 7.1.

[dmhendricks]

I agree that we have different visions and approaches. I hope that you continue to develop yours as I would like to borrow from it as I have time.