search

sapioit / phpliteadmin

Automatically exported from code.google.com/p/phpliteadmin
1 stars 0 forks source link

External header #214

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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!

Original issue reported on code.google.com by teryaki1...@googlemail.com on 15 May 2013 at 10:26

GoogleCodeExporter commented 9 years ago 
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.

Original comment by crazy4ch...@gmail.com on 15 May 2013 at 11:09

GoogleCodeExporter commented 9 years ago 
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:

Original comment by teryaki1...@googlemail.com on 15 May 2013 at 12:29

Attachments:

GoogleCodeExporter commented 9 years ago 
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.

Original comment by dreadnaut on 15 May 2013 at 7:19

GoogleCodeExporter commented 9 years ago 
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.

Original comment by teryaki1...@googlemail.com on 15 May 2013 at 11:37

GoogleCodeExporter commented 9 years ago 
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.

Original comment by crazy4ch...@gmail.com on 16 May 2013 at 8:08

GoogleCodeExporter commented 9 years ago 
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.

Original comment by teryaki1...@googlemail.com on 16 May 2013 at 11:04

GoogleCodeExporter commented 9 years ago 
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.

Original comment by crazy4ch...@gmail.com on 16 May 2013 at 3:50

GoogleCodeExporter commented 9 years ago 
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

Original comment by teryaki1...@googlemail.com on 16 May 2013 at 5:56

GoogleCodeExporter commented 9 years ago 
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?

Original comment by teryaki1...@googlemail.com on 17 May 2013 at 7:39

GoogleCodeExporter commented 9 years ago 
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)

Original comment by teryaki1...@googlemail.com on 20 May 2013 at 11:13

GoogleCodeExporter commented 9 years ago 
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.

Original comment by dreadnaut on 21 May 2013 at 8:11

GoogleCodeExporter commented 9 years ago 
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?

Original comment by teryaki1...@googlemail.com on 22 May 2013 at 10:58

GoogleCodeExporter commented 9 years ago 
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.

Original comment by dreadnaut on 11 Jun 2013 at 10:12

GoogleCodeExporter commented 9 years ago 
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!' />"; } );

Original comment by dreadnaut on 17 Jun 2013 at 10:10

Attachments:

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

Original comment by dreadnaut on 17 Jun 2013 at 10:12