Combining plugins, is it ok ?

vrijvlinder

I have been delving into how plugins work and are constructed. Made my own based on parts of other plugins I liked and or modified them to my needs. I thought about this one I am making which I would like to expand.

I could combine them them via :

Go through each plugin file and remove the plugin header.
Create a loader.php file.
example:

?php
/*
Plugin Name: Combined Plugin
Description: Contains plugin a, plugin b and plugin c
*/

include dirname(__FILE__) . '/plugin-a.php';
include dirname(__FILE__) . '/plugin-b.php';
include dirname(__FILE__) . '/plugin-c.php';

But this just calls the plugins from their whereabouts , Could I remove headers and just use the parts of the plugins and put them in the same file? Like a Master plugin guess. And also call that file from the theme php, I am not sure one can package plugins with themes.

x00

This is not how you combine plugins.

plugin use hooks which are called in parallel to the applications. The whole design ethos for this framework is parallel development.

You can use a arbitrary number of hooks per event. So two plugins can use the same hooks.

Plugins can also have hooks, and can work in parallel to each other.

Usually when a plugin require another, then that is put in the requirements. The require pluign need to be enabled first.

Enabled plugin are autoloaded. They can also used each other's resourced when loaded.

Some pluign resources are auto loaded, however this is more open to preference/convention.

vrijvlinder

I see..

So if I want to use another plugin's resources then what I do is put those requirements into it, basically just calling the plugin, which would have to be installed and enabled for it's resources to be accessible?

That is the rub, that multiple plugins need to be installed and enabled for one plugin to work..

businessdad

@vrijvlinder said:
That is the rub, that multiple plugins need to be installed and enabled for one plugin to work..

That's normal, they are called "requirements".
After all, you have to install a whole Operating System just to use Photoshop.

vrijvlinder

I found that for Some plugins that have style sheets, I can just style it in the custom.css and the plugin style sheet becomes redundant. But not the plugin, because for the style to even show, a person needs to install the plugin...
I could add styles for all the plugins into my themes I suppose...so they all match, and require or invite people to use the plugins

businessdad

Personally, I greatly prefer the self contained design. Everything related to a plugin stays inside plugin's folder. However, you can indeed provide an "override stylesheet" that makes all plugin look consistent. The only issue you might have is that some plugins may adopt their own, independent styles, that you would not cover.

What I usually do in my plugins is using styles only to handle element positions and sizes (width, height, and so on), but I don't touch fonts and colours. This way, they will look consistent regardless of what theme is used (as long as some basic styles are maintained. Important rule for Developers: "thou shalt not mess with the look & feel, leave it to Designers".

mcu_hq

What I usually do in my plugins is using styles only to handle element positions and sizes (width, height, and so on), but I don't touch fonts and colours.

Yea, this is good advice. You should also try to use the default classes/IDs so it at least conforms with the default Vanilla theme. Everything else should fall into place from there if the custom theme simply overrides the default colors in the already established classes.

businessdad

@mcu_hq said:
You should also try to use the default classes/IDs so it at least conforms with the default Vanilla theme.

Precisely. I use the common classes, such as Info, Button, SmallButton, etc so that everything "auto styles" itself. Best approach ever, zero maintenance.

vrijvlinder

you can indeed provide an "override stylesheet" that makes all plugin look consistent.

that is what I would like to ultimately achieve....somehow

I use the common classes, such as Info, Button, SmallButton, etc so that everything "auto styles"

I do this too which is how I realized it could just be included in the theme custom.css. An example of a plugin with style sheet, Categories2Menu. It's style comes looking like the default vanilla theme. A person would have to code it to match another theme. But if the theme already has that style in it then all they need to do is install the plugin....That to me is zero maintenance in the long run no?

Anonymoose

It is better, when programming, to have several independent components which can be disabled/enabled/changed rather than putting everything into one big long component. This applies to plugins. Don't combine code into one master plugin. If something goes wrong in the code, you will have a harder time debugging.

vrijvlinder

@Anonymoose:

Yes that makes sense, when you look at it that way. It is better to have components in a modular system than a master combo that if it fails it all goes to hell.
It would be great to have a plugin style sheet for all the plugins. That seems to be the biggest issue with themes and plugins like Vote. And others that come out wrong depending on the theme used.

I pretty much need to install every plugin to make sure it works well with the themes I make and write css for each one and each theme. There has to be a better way, or is this something to leave up to the user and for them to style it as needed?

Having a hard time letting go of the themes, it's like artwork that is never finished

If there was a way to combine the plugin stylesheets it would save work....I think

x00

It is better for your plugin though that you have individual, style sheets, that that's the modular design that you talk about. It is up to you how you structure it. Post processing is another issue.

Actually 2.1 will be doing exactly that. You will have separate style sheet, and it will combine some of them cache them. You don't want to combine them all in one becuase of the domino effect. Personality I would prefer control how it works myself.

Word of warning, minfication and obfuscation are essentially flawed and imperfect concepts with regard to javascript. They regularly corrupt code. The only reason why it is used, if tested to not to be corrupt in that case then released. I may work 80-90% of the time, but it is unreliable, when you're just doing it blind.

vrijvlinder

yes I understand, I though about this all night, The benefit from having them styled separate is that when you change themes the plugin remains intact for the next theme. This would be ok if every theme has the style for that plugin, I think I am going to make the effort to make all the themes I made, compatible with the most used plugins.

I feel that as a theme maker, I am responsible for making it work with everything.
Maybe what I need is just for my own needs to be able to create themes more efficiently.

vrijvlinder

@x00 , it would be great if you could change the name style of apt ads from .AptAdInstructions to .Aside because the colors do not go with the admin themes. However .Aside is the help div name in the dashboard and it would inherit the style.

well maybe not, I think adding the apt ads css to the dashboard design is the way to go. I will add .AptAdInstuctions to the customadmin.css so it will inherit

Linc

You can include RequiredPlugins and RequiredApplications in your plugin's info array. That makes sure the other plugins/apps are already turned on before yours is. That's how you stack dependencies in Vanilla.

x00

Admin themes are of little concern to me right now. Low priory.

vrijvlinder

yea I know, it's ok I will add the code to the admin themes I made. Don't worry