External header
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
Comments (15)
-
-
Account Deleted 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>
-
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 -
Account Deleted 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 -
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 -
Account Deleted 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 -
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 -
Account Deleted 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 -
Account Deleted 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 -
Account Deleted 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 -
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 -
Account Deleted 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 -
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 -
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
-
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 - Log in to comment
Reported by
crazy4chrissi
on 2013-05-15 11:09:05