External header

[Former user]

Originally reported on Google Code with ID 214

Hey
I mentioned in issue 129 the idea to provide plugins for pla, but i believe fixing
bugs is more important than any new complicated steps.
Any way im using some additional javascripts (jquery plugins) and styles to use pla
in a more comfortable way (WYSIWYG Editor, Date picker etc.).
All i need for that is an external "header.php" and an additional line in pla (line
2020 before </head>) which goes like this:

<?php
$header_inc = "header.php";
if(file_exists($header_inc)) include($header_inc);
?>

it would be nice to add it, so i dont need to add my self in every new version.
of course i can share these addons, in case any one like to use pla as CMS or for any
other purpose!

Reported by teryaki1963 on 2013-05-15 10:26:36

[Christopher Kramer]

I know you do this like this because it is the most simple solution. When I think about
this, I would prefer a more advanced plugin interface but I am not sure whether this
is now the time for it.

First idea: Instead of having one header.php, in which you have to add all plugins,
I think it would be nicer to have a folder like "addons" where every add-on has one
php-file and pla iterates through this folder and includes all of them in the header.
It has the huge advantage that addons can then be just dropped in the folder and removed
individually without changing stuff in a file.

And then I have lots of other ideas of how to have a more advanced plugin interface,
but as I said, we should probably not do this before we have improved our architecture.

Of course it would be cool to see what addons you have so far.

Reported by crazy4chrissi on 2013-05-15 11:09:05

[Former user]

Hey Christopher
We can leave "header.php" up to the user how he likes to edit it or which folder name
he wants. In my case i use "header.php" only to register the plugins which all saved
in a folder "inc". This might be very simple way but also very effective to create
many useful addons.
Here is an example how i used it:

----------------
<script src="inc/jquery/js/jquery-1.9.1.js">/* Implementing JQuery */</script>

<script type="text/javascript" src="inc/cleditor/jquery.cleditor.js"></script>
<link rel="stylesheet" type="text/css" href="inc/cleditor/jquery.cleditor.css" />

<link rel="stylesheet" href="inc/datepicker/public/css/default.css" type="text/css">
<script type="text/javascript" src="inc/datepicker/public/javascript/zebra_datepicker.js"></script>
<script type="text/javascript" src="inc/datepicker/examples/public/javascript/core.js"></script>

<script type="text/javascript">
  $(document).ready(function() {
      $.cleditor.defaultOptions.width = "100%"; 
      $.cleditor.defaultOptions.height = 300;
      $(".text_textarea").cleditor(); // adding cleditor
      $(".date_textarea").Zebra_DatePicker(); // adding date picker
  });
</script>
<style>
/* Changing the height of all textareas which consist of 1 line */
.title_textarea, .cat_textarea, .comments_textarea, .prop_textarea, .author_textarea,
.date_textarea, .sort_textarea{ height:20px; }
</style>
------------------

The class names of the textareas are unique according to column name, as you know:
Class = "columnName_textarea"
And here is how my example looks like:

Reported by teryaki1963 on 2013-05-15 12:29:39

<hr> * Attachment: add_plugins.png<br>

[dreadnaut]

Adding a plugin interface now sounds a bit dangerous, with all the plans to move stuff
around. However, we should start at some point :-)

Maybe for the moment you would be better off switching to a "split mode" installation
and concatenating resources/phpliteadmin.js with jQuery and the other libraries you
need. This way you wouldn't have to edit any files when upgrading, just regenerate
the js file.

Reported by dreadnaut on 2013-05-15 19:19:03

[Former user]

Offering plugins ability is not a simple matter which can be solved with this additional
line:

<?php
$header_inc = "header.php";
if(file_exists($header_inc)) include($header_inc);
?>

i realy dont like to make things complicated :-D

As you said, we should start at some point and the most important is the head part.
Also i have my reasons why we need a php file and not just *.js. For some addons we
need php-variables which already declared in the upper part of pla (thats why the include()
method).

  >>This way you wouldn't have to edit any files when upgrading, just regenerate the
js file.

We are not responsible whether a user has header.php or not! We even dont need to offer
header.php to the download version. And with this method even if i upgrade pla, header.php
(in case i created one) remains untouched.
So its up to the user if he likes to add the file or not. As an apportunity for other
developers to model and use pla the way they like to, without changing code in pla
file.

Reported by teryaki1963 on 2013-05-15 23:37:44

[Christopher Kramer]

I know you are including a php because you want to use variables and such, but this
also means you will likely get into trouble when updating anyway, as we have not defined
any interface that you can assume remains stable. It is very likely that we move stuff
around, change names or stuff like this and your code would get broken. Adding the
include-line again would be the simplest of changes you'd need to do when updating.

Reported by crazy4chrissi on 2013-05-16 08:08:50

[Former user]

1. Yes i know all these matters that might happen in the future, but even such changes
wont affect all of addons. 
2. And even famous programs have done drastic changes such as sqlite, php etc. this
does not mean, users are in trouble.
3. we should weigh advantages and disadvantages! i thought much about the idea and
i believe that advantages predominate

  >>Adding the include-line again would be the simplest of changes you'd need to do
when updating.

1. I know but its the same as adding external config file. I dont need to open pla
file and add the line by every new update.
2. When i share a new addon for pla, the line must be already included otherwise i
must tell the users to add the line by themselves. this means, im acting separately
from pla and no one can share any addons here.

PLA started as experimental and this is the secret of success (in my opinion). Now
its a great tool and with this step (addon cut) we offer something that other programs
dont have.

Any way i dont like to push things. i only thought that you liked the idea of a plugin
interface, and here is how we can start it in a simple way. You also see from the upper
2 examples (according to your request), that it works fine.

Reported by teryaki1963 on 2013-05-16 11:04:17

[Christopher Kramer]

I didn't say I don't like your idea, it's just I like discussing before deciding and
therefore, I tend to take the opposite opinion in the discussion just to have both
sides ;-)

In fact I would love to see addons like yours for pla around and we need to provide
a plugin interface for this some time.

Of course we can say today: Okay, we do it puristic today and follow your approach,
and one day we add a real plugin interface and ask plugin developers to use this instead
and one day drop the old one completely.
In fact I think this might be a good idea.
Let's put it like this: It does not really hurt to add this now, the only problem is
that it's very likely that plugins don't work with new versions.


Still, I don't like the idea of having one header.php file. You'd need to tell the
user what to do in there. Let's assume a user wants to use 2 different plugins from
2 different developers, both providing some header.php. Shouldn't be the user's task
to concatenate stuff.
Instead, I would just define some folder like "addons" and include any php-file in
there. This way, the user can just drop plugin-files in there to install them.

Reported by crazy4chrissi on 2013-05-16 15:50:30

[Former user]

Im doing the same way as JQuery did. To use JQuery or add plugins to your site, it needs
some knowlege about it. So if you downloaded a jquery plugin that doesnt mean it woks
automaticaly:
1. download the plugin
2. set the path to the plugin in the right position (mostly <head> part) in your site
3. add some javascript according to the plugin instructions 
4. check the right version if it didnt work

thats exactly what we gonna make if we offer plugins for pla

1. download the plugin
2. open header.php (if you dont have it, create one and save in same folder of pla)
3. set the right path of the plugin
4. add some code (or no need)
Done

Ill also add some plugins for downloading as example at the beginnig 

Reported by teryaki1963 on 2013-05-16 17:56:59

[Former user]

Ok, i've changed my methode: instead of header.php, we read all folders in folder:addons.
That means every addon is in its own folder. So to create an addon, the developer need
to create "index.php" (with code inside) in that folder.

Now the function for pla:

<?php

function addons_header(){
  $addonsPath = "./addons/";
  foreach (new DirectoryIterator($addonsPath) as $d)
  {
    $dname = $d->getFilename();
    $dpath = $addonsPath.$dname;
    if(is_dir($dpath) && $dname != "." && $dname !="..")
    {
      $fpath = $dpath.'/index.php';         
      if(file_exists($fpath)) include($fpath);
    }
  }
}

addons_header();

?>

The only probleme i have with this method, is sorting the addons the way i want to.
e.g. jquery must be in the first line otherwise the other addons which depend on jquery,
wont work.
Easy solution but not the best is to rename the folder of jquery to "0".

In havalite CMS, i implimented jquery as a part of the project cause i need for the
interface and many other plugins.

What you think?

Reported by teryaki1963 on 2013-05-17 19:39:46

[Former user]

I made some changes with a better solution:

The addons folder looks as follow:

addons
   |__index.php
   |__addon1
        |__index.php
   |__addon2
        |__index.php
   |__addon3
        |__index.php


In first "index.php" of the addons folder we can leave empty or if we need a special
order of some or all plugins, we can set it in Array = myaddons:

<?php
$myaddons = array('addon3');
?>

And the rest of the addons will be sorted automatically:

<?php

function addons_header(){

   $addonsPath = "./addons/";
   $addonsSort = array();

   if(file_exists($addonsPath.'index.php')){
      include($addonsPath.'index.php');
      if(isset($myaddons)) $addonsSort = $myaddons;
   }

   if(is_dir($addonsPath)){

      if(count($addonsSort) > 0){
         foreach($addonsSort as $d){
            $fpath = $addonsPath.$d.'/index.php';
            if(file_exists($fpath)) include($fpath);
         }
      }

      foreach (new DirectoryIterator($addonsPath) as $d){
         $dname = $d->getFilename(); 
         $dpath = $addonsPath.$dname;
         if(is_dir($dpath) && $dname != "." && $dname !=".." && !in_array($dname, $addonsSort)){
            $fpath = $dpath.'/index.php';           
            if(file_exists($fpath)) include($fpath);
         }
      }
   }
}

addons_header();

?>

This way we can also add a new tab "Addons" to pla viewing all installed addons and
maybe the ability to edit index.php (if its permitted)

Reported by teryaki1963 on 2013-05-20 11:13:24

[dreadnaut]

Including a bunch of files is not exactly a plugin API. Although this solves the problem
you have, I don't think it would be very useful for PLA overall.

Adding lines to the <head> tag is just one of many possible extensions that user might
want, and that would be better catered with a decent system of callbacks / events.

Temporarily, we could add a $html_head_content variable which could be filled in the
configuration file, and then sent to output inside the <head> tag. Less overload, easier
to replace later.

Also I'm still not sure why you don't want to add your js code the phpliteadmin.js,
as I suggested above.

Reported by dreadnaut on 2013-05-21 20:11:52

[Former user]

I didnt say its plugin API. As you see, i left issue 129 and started a new one here
to seperate between the 2 subjects. To make a real plugin API we need to rewrite the
whole code in pla, but i dont want to start this now till we have most bugs fixed!
Im also using callbacks in "Havalite CMS" but i have another code structure to include
the plugin in many places such as (start, header, content, footer, sidebar).

>>Also I'm still not sure why you don't want to add your js code the phpliteadmin.js,
as I suggested above.

I already explained above why we need php and not only phpliteadmin.js
Also, using $html_head_content in config file is same as using phpliteadmin.js this
wont help much

e.g. last addon i made: 
if i'm in edit mode i would like to go back to continue editing. 
First i need to know, if its saved by reading $confirm
than wait till site is loaded
than send me back to same $pk

its a simple addon but also needs php and not just js

The function "addons_header()" i wrote above doesnt require from the user to have an
addon folder, if he doesnt need. So what's the problem by adding it?

Reported by teryaki1963 on 2013-05-22 10:58:56

[dreadnaut]

Sorry for disappearing (again), life getting in the way :-p

> The function "addons_header()" i wrote above doesnt require from the user to
> have an addon folder, if he doesnt need. So what's the problem by adding it?

In my opinion it's a fine function, but it's very specific and not reusable. It solves
one problem but adds complexity, directories, filesystem operations, etc.  So it's
easy to add it today, but we'll have trouble to work with it in the future —or we would
just remove it soon.

What about a more general solution that can be reused in other occasions? For example
a minimal "hook" system, with two functions

Plugin::hook($event, $callable)
Plugin::runHook($event)

you define your hook by adding this to your config file

Plugin::hook('html.head', 'your_function')

and we make sure to call the function at the right point of the page

 ...
 <title>...</title>
 <?php Plugin::runHook('html.head') ?>
</head>

This way we can delay choosing a directory structure or adding auto-loading until we
know what we want from it, but you should be able to output anything you want inside
the <head> tag.

That done, we can add other hooks, e.g. html.footer, or database.load.

Reported by dreadnaut on 2013-06-11 10:12:08

[dreadnaut]

Here's some code to follow the (maybe vague) words above. Save the Plugin.php file under
src/trunk/classes/, add this line to src/trunk/index.php

<?php Plugin::runHook('html.head'); ?>

and register your plugin somewhere in your config file, using either the function name

Plugin::hook('html.head', 'my_cool_function' );

or an anonymous function (5.3+ only!)

Plugin::hook('html.head', function(){ echo "<meta stuff='yes!' />"; } );

Reported by dreadnaut on 2013-06-17 10:10:11

<hr> * Attachment: Plugin.php

[dreadnaut]

Er, I forgot: the 'runHook' line should be added inside the <head> tag in index.php,
around line 563.

Reported by dreadnaut on 2013-06-17 10:12:08