Should the demo plugin be separated from the main framework?

[michaeluno]

I'm wondering whether the demo plugin should be a separate plugin then make the main framework plugin just serve as a framework installer which just includes the framework file(s).

This way, each developer who uses the framework does not have to call include( 'admin-page-framework.min.php' ). However, their plugin or theme will need to require the framework installer to be installed as a dependency so their products will not be portable.

But I sense that some don't mind it and rather prefer that way. I'm not completely sure why but maybe it can avoid library conflicts or something.

[pcraig3]

I'm using your library for several of my own on the one website I'm doing (I've never done others, so never done this before), and instead of including your library file each of my other plugins, I've just installed the Admin Page Framework Demo Plugin without activating it. All of my other plugins are then linking to library in the demo plugin.

I've activated your demo plugin from time-to-time to figure out how certain features work, but in the future it's probably just going to stay deactivated.

Hard-coding a dependency to an external plugin seems not the best solution to me, but this way I get all the updates and, for practical purposes, leaving it deactivated doesn't really pose a problem.

Long story short: the demo and the library together helped me in development and since WordPress doesn't really do inter-plugin dependencies very well, I can't see a practical value in separating them.

[michaeluno]

Interesting.

So you link the library file from multiple plugins to avoid updating the library manually and you don't mind keeping the demo plugin for that.

That makes me think to separate the demo plugin from the framework distribution package though. There might be a developer who uses the library like you do liking to multiple other plugins and works for a client to create a production site. In that case, a plugin named demo might not be suitable.

Anyway, thanks for your opinion and the use case. It was very helpful.

[pcraig3]

Yeah, that's about the size of it.

The demo plugin helped me out a lot during development, so I liked that they came together. I can see the argument that it's not very (air quotes) 'professional' to have the name say 'Demo,' but for the site I've got now it makes very little difference.

[baskettcase]

Yes I think it would be good. In the last couple of days I have tried a bunch of different frameworks and that's pretty much how all of them do it (load up framework) then demo would be a different plugin. That should solve the problem with needing to rename the class in our plugin when the demo is loaded right?

[michaeluno]

@baskettcase Yes.

One problem I can predict is that if there is a breaking change in a future framework update, it will affect all the sites of the framework users. The framework users will be not only developers but also their product users.

Say, there is a developer who works for a client and builds a site for them by using the framework and the framework loader plugin. When the framework loader plugin receives an update notice then the client updates it and if it includes a breaking change, the site may break.

Another scenario is that, say, there is a plugin that uses the framework and its framework loader as an separate plugin. The plugin users will receive an update notice of the framework loader plugin. If they update the framework and if it includes a breaking change, their sites may break.

Currently, it is assumed that each developer includes their own copy of the framework file(s). In order to update the framework, they have to copy the file manually. If the updated framework includes a breaking change, the developer has a chance to see it at this point without affecting his/her product users. So it is safer than relying on the framework loader updates.

Having said that, if framework users choose to do that while understanding the risks of it, there should not be a problem.

[baskettcase]

@michaeluno and those are really good points. It seems like it would be a good idea to give developers the option though. I had to rename the class I included in my project since to have the demo running at the same time would cause issues. That would be good to have changed also, unless that was just because I was doing something wrong? I thought you mentioned that in one of your tutorials though. I don't know the full ramifications of a decision like this one you are asking about, so Im only giving my, not as educated as it should be, opinion :)

[michaeluno]

@baskettcase Yeah. Also renaming classes can be an obstacle for those who just want to try the framework. For a starter, it is hard to tell whether he/she is doing right or wrong when they encounter a problem and whether it is due to the modification of renaming classes they made. So the default method of loading the framework may ought to be using a loader plugin. And renaming classes can be for advanced users.

Thanks for your opinion.

[baskettcase]

It just occurred to me as Im writing another plugin that maybe you could make use of namespaces somehow? They are still new to me since I started using composer, so maybe that wouldn't be helpful.

[michaeluno]

I could not find a way to use namespaces while supporting PHP v5.2.4. You can suggest me a way if you know how.

[baskettcase]

Drop 5.2 support? Isn't 5.3 EOL also?

[michaeluno]

You may check this chart. https://wordpress.org/about/stats/

Dropping v5.2 is likely not an option as long as WordPress supports it. Once I had a customer for my paid plugin claiming that she got a PHP error due to a function call that is not supported in v5.2.x or below caused by my plugin. And she demanded a refund for that although I updated the plugin right away. It was like a year ago.

I suspect many free hosting services still use PHP 5.2.x as their default server configuration.

[baskettcase]

Ah wow, I see. Wow, that's pretty bad.. that means there are a lot of unpatched versions of WordPress out there, that's pretty scary. Well.. I see why you need to support 5.2 then heh, Bummer since there are so many benefits to more recent versions of PHP!! :(

[vladkucherov]

Hi guys,

Personally I would prefer a sepearate version of the framework from the demo. but if that's not an option and maybe some would prefer the demo in the package, maybe there should be a trigger to turn off the loading of the demo?

FILE: admin-page-framework-demo.php

if(!defined('APFDEMO_LOAD') {
    define('APFDEMO_LOAD', true);
}

if(APFDEMO_LOAD) {
    /* Load examples */
    include( APFDEMO_DIRNAME . '/example/example-bootstrap.php' );
}

I think this may be the best solution for now until you'll decide what to do. personally I prefer the plugin as a plugin and not as a library inside my code.

Vlad.

[michaeluno]

@vladkucherov in v3.5.0 the demo part will be optional.

You may try the 3.5.0b branch. https://github.com/michaeluno/admin-page-framework/tree/3.5.0b (Download)

I prefer the plugin as a plugin and not as a library inside my code.

I'm curious about whether you don't mind requiring your users to install an extra plugin for your products.

[vladkucherov]

@michaeluno No I don't mind because clients now understand that not 100% of the product they purchase is written by me. They know that if I would be required to recreate every single thing, the price would much more then it should be.

By having a plugin instead of a lib I get chance to receive updates from WP instead of updating things myself - and that's something priceless to me on the long term.

[michaeluno]

@vladkucherov Interesting point. Just be careful if anything breaks with the framework updates.

[vladkucherov]

@michaeluno Just because updating may become easier, doesn't remove the requirement for the developers to test everything after an update - this includes all the plugins, not just APF.

[michaeluno]

v3.5.0 has been released.