php-general Digest 27 Aug 2012 17:34:15 -0000 Issue 7939
Topics (messages 318870 through 318878):
Re: multiple forms one page
318870 by: tamouse mailing lists
318871 by: Adam Richardson
318878 by: Tedd Sperling
Re: What's the best way to make a dynamic plugin architecture?
318872 by: Stuart Dallas
318874 by: Mark
318875 by: Stuart Dallas
318876 by: Mark
318877 by: Stuart Dallas
Movable Type (MT) *client*
318873 by: Mihamina Rakotomandimby
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Sun, Aug 26, 2012 at 11:08 PM, Rosie Williams
<rosiemariewilli...@hotmail.com> wrote:
>
> Hi all,
> I am a newbie to PHP. I have several php forms which were originally on
> separate pages now included in the one page. Each form had the following code
> in it:
> function mysql_fix_string($string){ if (get_magic_quotes_gpc()) $string =
> stripslashes($string); return mysql_real_escape_string($string);}
> function mysql_entities_fix_string($string){ return
> htmlentities(mysql_fix_string($string));}
> However I am only able to include it in one of the forms on the new page with
> multiple scripts due to the fatal error that I can only declare the function
> once. So for testing I have commented these lines out of the other scripts. I
> need to know what the security implications of this are? Do the scripts that
> do not contain these lines run without it or is it included automatically
> every time the database is accessed regardless of which script is accessing
> it?
> If not how do I deal with it?
> thanks in advanceRosie
Hi, Rosie, welcome!
This is something you will likely encounter again, so it is good to
learn it now.
You can put the two functions into another php file, and include that
file in your main script using include_once or require_once (there is
a difference that you might want to read up on at some point). If you
include this before you start your form processing, the functions will
be available to you at the point you need them. You only need do this
once in the php script where you will be using them, so you can safely
delete all the other occurances of the function definitions.
The nice part is, really, that you can use that same include file in
other projects as you go along, saving retyping the code. This is
something that you may want to think about for other such functions as
well. Modularity and code reuse are one of the big ways to achieving
more efficiency in your work.
http://us.php.net/manual/en/function.include-once.php
http://us.php.net/manual/en/function.require-once.php
(cf. http://us.php.net/manual/en/function.require.php to learn how the
"require" differs from the "include")
Best of luck,
Tamara
aka tamouse__
--- End Message ---
--- Begin Message ---
On Mon, Aug 27, 2012 at 12:08 AM, Rosie Williams
<rosiemariewilli...@hotmail.com> wrote:
>
> Hi all,
> I am a newbie to PHP. I have several php forms which were originally on
> separate pages now included in the one page. Each form had the following code
> in it:
> function mysql_fix_string($string){ if (get_magic_quotes_gpc()) $string =
> stripslashes($string); return mysql_real_escape_string($string);}
> function mysql_entities_fix_string($string){ return
> htmlentities(mysql_fix_string($string));}
> However I am only able to include it in one of the forms on the new page with
> multiple scripts due to the fatal error that I can only declare the function
> once.
You only have to declare the function(s) once, then you can use them
later in the page. You can also put code into files and then
dynamically include them in other files to make it easier to share
functionality.
> So for testing I have commented these lines out of the other scripts. I need
> to know what the security implications of > this are?
For security, the simple rule (at least in terms of statement of
intent, not necessarily in terms of implementation) is that you should
validate input and escape output according to context. Without seeing
more code, it's hard to tell what this means for your particular
example.
> Do the scripts that do not contain these lines run without it or is it
> included automatically every time the database is accessed regardless of
> which script is accessing it?
> If not how do I deal with it?
> thanks in advanceRosie
Hard to know from your example. There are some great resources
covering general PHP security practices that can help you get up to
speed a bit. Here's an oldie but goodie that might help shed some
light on some of the code you're seeing:
http://www.ibm.com/developerworks/opensource/library/os-php-secure-apps/index.html
Happy learning!
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On Aug 27, 2012, at 12:08 AM, Rosie Williams <rosiemariewilli...@hotmail.com>
wrote:
>
> Hi all,
> I am a newbie to PHP. I have several php forms which were originally on
> separate pages now included in the one page. Each form had the following code
> in it:
> function mysql_fix_string($string){ if (get_magic_quotes_gpc()) $string =
> stripslashes($string); return mysql_real_escape_string($string);}
> function mysql_entities_fix_string($string){ return
> htmlentities(mysql_fix_string($string));}
> However I am only able to include it in one of the forms on the new page with
> multiple scripts due to the fatal error that I can only declare the function
> once. So for testing I have commented these lines out of the other scripts. I
> need to know what the security implications of this are? Do the scripts that
> do not contain these lines run without it or is it included automatically
> every time the database is accessed regardless of which script is accessing
> it?
> If not how do I deal with it?
> thanks in advanceRosie
My advice -- place your common functions into one file (i.e., functions.php)
and:
include_once("includes/functions.php");
At the start of every script that needs any of the functions contained therein.
As for rolling several forms into one, here are some of the ways I do it:
http://sperling.com/php/step/
http://sperling.com/php/submit/
Cheers,
tedd
PS: If anyone see's anything in error, please feel free to correct me. As a
very talented harmonica player once said "Sometimes I suck and sometime I blow."
--- End Message ---
--- Begin Message ---
On 26 Aug 2012, at 19:42, Mark <mark...@gmail.com> wrote:
> Envision the following plugin architecture:
>
> class PluginLoader
> {
> }
>
> interface PluginInterface
> {
> .. some function definitions ..
> }
>
> class PluginOne implements PluginInterface
> {
> }
>
> class PluginTwo implements PluginInterface
> {
> }
>
> The PluginLoader is loading the plugins.
> The PluginInterface defines an interface which each plugin has to implement.
> PluginOne and PluginTwo are plugins that implement the interface.
>
> Each plugin (PluginOne and PluginTwo) are stored in their own folders.
> So the folder structure would be somewhat like this:
> |- Plugins
> |- - PluginOne
> |- - - PluginOne.php
> |- - - other possible files
> |- - PluginTwo
> |- - - PluginTwo.php
> |- - - other possible files
> |- PluginLoader.php
> |- PluginInterface.php
>
> Now making this structure isn't an issue. I can do all of that just
> fine. The place where i'm actually going to make a plugin instance is
> where things get a little more complicated. The PluginLoader simply
> reads all the dirs in the Plugins folder and tries to find a filename
> with the same dir. So if it reads the dir Plugins/PluginOne it will
> try to include the PHP file: Plugins/PluginOne/PluginOne.php. That's
> fine and working.
>
> To actually make a plugin instance i can do two things that i know of:
> 1. use eval like so: eval('$obj = new '.$pluginName.'();'); and
> register it to the PluginLoader.
No need to use eval, you can simply do this:
$obj = new $pluginName();
See here: http://php.net/language.variables.variable
> 2. Let the plugin itself (so in this case PluginOne.php) open itself
> and register it to the PluginLoader.
>
> With the first option i have to do eval which i try to avoid if possible.
> With the second solution the PluginLoader probably has to be a singlethon.
Why does it need to be a singleton?
> Now my question is: what is the right way of loading plugins like
> this? Is there some other option then the two i described above? My
> PHP limitations are the newest version so no limitation there :)
> I'm kinda leaning towards the second option now since that seems to be
> quite stable and not very error prone. The eval one is much easier to
> break :p
If you're happy for each plugin to be in a separate directory then what you
have in option 1, minus the eval, will work perfectly well. I don't know what
your use case is but if there's a chance a single plugin might want to provide
several classes then I'd require an init.php in each plugin folder and have
that register the class names with the class loader. It could also then pass
along some meta information such as a description of what each class does. If
this is for use in web requests you might want to stick to what you currently
have as there's a lot less overhead.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On Mon, Aug 27, 2012 at 12:41 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 26 Aug 2012, at 19:42, Mark <mark...@gmail.com> wrote:
>
>> Envision the following plugin architecture:
>>
>> class PluginLoader
>> {
>> }
>>
>> interface PluginInterface
>> {
>> .. some function definitions ..
>> }
>>
>> class PluginOne implements PluginInterface
>> {
>> }
>>
>> class PluginTwo implements PluginInterface
>> {
>> }
>>
>> The PluginLoader is loading the plugins.
>> The PluginInterface defines an interface which each plugin has to implement.
>> PluginOne and PluginTwo are plugins that implement the interface.
>>
>> Each plugin (PluginOne and PluginTwo) are stored in their own folders.
>> So the folder structure would be somewhat like this:
>> |- Plugins
>> |- - PluginOne
>> |- - - PluginOne.php
>> |- - - other possible files
>> |- - PluginTwo
>> |- - - PluginTwo.php
>> |- - - other possible files
>> |- PluginLoader.php
>> |- PluginInterface.php
>>
>> Now making this structure isn't an issue. I can do all of that just
>> fine. The place where i'm actually going to make a plugin instance is
>> where things get a little more complicated. The PluginLoader simply
>> reads all the dirs in the Plugins folder and tries to find a filename
>> with the same dir. So if it reads the dir Plugins/PluginOne it will
>> try to include the PHP file: Plugins/PluginOne/PluginOne.php. That's
>> fine and working.
>>
>> To actually make a plugin instance i can do two things that i know of:
>> 1. use eval like so: eval('$obj = new '.$pluginName.'();'); and
>> register it to the PluginLoader.
>
> No need to use eval, you can simply do this:
>
> $obj = new $pluginName();
>
> See here: http://php.net/language.variables.variable
Ahh right, i completely forgot about that option. That might just work
the way i want it :)
>
>> 2. Let the plugin itself (so in this case PluginOne.php) open itself
>> and register it to the PluginLoader.
>>
>> With the first option i have to do eval which i try to avoid if possible.
>> With the second solution the PluginLoader probably has to be a singlethon.
>
> Why does it need to be a singleton?
Well, i would then do something like this from within the included
plugin file after the class:
PluginLoader::getInstance()->registerPlugin(new PluginOne());
Or something alike.
>
>> Now my question is: what is the right way of loading plugins like
>> this? Is there some other option then the two i described above? My
>> PHP limitations are the newest version so no limitation there :)
>> I'm kinda leaning towards the second option now since that seems to be
>> quite stable and not very error prone. The eval one is much easier to
>> break :p
>
> If you're happy for each plugin to be in a separate directory then what you
> have in option 1, minus the eval, will work perfectly well. I don't know what
> your use case is but if there's a chance a single plugin might want to
> provide several classes then I'd require an init.php in each plugin folder
> and have that register the class names with the class loader. It could also
> then pass along some meta information such as a description of what each
> class does. If this is for use in web requests you might want to stick to
> what you currently have as there's a lot less overhead.
Yeah, if i extend it more that will certainly be an requirement.
>
> -Stuart
>
> --
> Stuart Dallas
> 3ft9 Ltd
> http://3ft9.com/
Thank you for your advice, really appreciated.
--- End Message ---
--- Begin Message ---
On 27 Aug 2012, at 14:29, Mark <mark...@gmail.com> wrote:
> On Mon, Aug 27, 2012 at 12:41 PM, Stuart Dallas <stu...@3ft9.com> wrote:
>> On 26 Aug 2012, at 19:42, Mark <mark...@gmail.com> wrote:
>>
>>> 2. Let the plugin itself (so in this case PluginOne.php) open itself
>>> and register it to the PluginLoader.
>>>
>>> With the first option i have to do eval which i try to avoid if possible.
>>> With the second solution the PluginLoader probably has to be a singlethon.
>>
>> Why does it need to be a singleton?
>
> Well, i would then do something like this from within the included
> plugin file after the class:
> PluginLoader::getInstance()->registerPlugin(new PluginOne());
>
> Or something alike.
I'm not sure I see what PluginLoader is doing? It makes more sense to me if you
register like so:
PluginLoader::getInstance()->registerPlugin('PluginOne');
Then you get an instance of the plugin:
$plugin = PluginLoader::getInstance()->factory('PluginOne');
Tho, even then I don't see what the PluginLoader is adding to the party.
> Thank you for your advice, really appreciated.
No probs.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On Mon, Aug 27, 2012 at 3:46 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 27 Aug 2012, at 14:29, Mark <mark...@gmail.com> wrote:
>
>> On Mon, Aug 27, 2012 at 12:41 PM, Stuart Dallas <stu...@3ft9.com> wrote:
>>> On 26 Aug 2012, at 19:42, Mark <mark...@gmail.com> wrote:
>>>
>>>> 2. Let the plugin itself (so in this case PluginOne.php) open itself
>>>> and register it to the PluginLoader.
>>>>
>>>> With the first option i have to do eval which i try to avoid if possible.
>>>> With the second solution the PluginLoader probably has to be a singlethon.
>>>
>>> Why does it need to be a singleton?
>>
>> Well, i would then do something like this from within the included
>> plugin file after the class:
>> PluginLoader::getInstance()->registerPlugin(new PluginOne());
>>
>> Or something alike.
>
> I'm not sure I see what PluginLoader is doing? It makes more sense to me if
> you register like so:
>
> PluginLoader::getInstance()->registerPlugin('PluginOne');
>
> Then you get an instance of the plugin:
>
> $plugin = PluginLoader::getInstance()->factory('PluginOne');
>
> Tho, even then I don't see what the PluginLoader is adding to the party.
Well, i'm making the classes up as i type. I don't actually have a
PluginLoader yet. Or rather, i'm just beginning to make it right now.
What it's doing is very simple. Read through the directory of the
plugins and load every single plugin it finds in memory. Then every
plugin registers the mime types it can handle. That information is
stored in the PluginLoader upon which some other place can call:
PluginLoader::pluginForMime("text/html"). Though i still have to take
a good look at that.
But you're right, i can use the factory pattern here.
>
>> Thank you for your advice, really appreciated.
>
>
> No probs.
>
> -Stuart
>
> --
> Stuart Dallas
> 3ft9 Ltd
> http://3ft9.com/
--- End Message ---
--- Begin Message ---
On 27 Aug 2012, at 14:52, Mark <mark...@gmail.com> wrote:
> On Mon, Aug 27, 2012 at 3:46 PM, Stuart Dallas <stu...@3ft9.com> wrote:
>> On 27 Aug 2012, at 14:29, Mark <mark...@gmail.com> wrote:
>>
>>> On Mon, Aug 27, 2012 at 12:41 PM, Stuart Dallas <stu...@3ft9.com> wrote:
>>>> On 26 Aug 2012, at 19:42, Mark <mark...@gmail.com> wrote:
>>>>
>>>>> 2. Let the plugin itself (so in this case PluginOne.php) open itself
>>>>> and register it to the PluginLoader.
>>>>>
>>>>> With the first option i have to do eval which i try to avoid if possible.
>>>>> With the second solution the PluginLoader probably has to be a singlethon.
>>>>
>>>> Why does it need to be a singleton?
>>>
>>> Well, i would then do something like this from within the included
>>> plugin file after the class:
>>> PluginLoader::getInstance()->registerPlugin(new PluginOne());
>>>
>>> Or something alike.
>>
>> I'm not sure I see what PluginLoader is doing? It makes more sense to me if
>> you register like so:
>>
>> PluginLoader::getInstance()->registerPlugin('PluginOne');
>>
>> Then you get an instance of the plugin:
>>
>> $plugin = PluginLoader::getInstance()->factory('PluginOne');
>>
>> Tho, even then I don't see what the PluginLoader is adding to the party.
>
> Well, i'm making the classes up as i type. I don't actually have a
> PluginLoader yet. Or rather, i'm just beginning to make it right now.
> What it's doing is very simple. Read through the directory of the
> plugins and load every single plugin it finds in memory. Then every
> plugin registers the mime types it can handle. That information is
> stored in the PluginLoader upon which some other place can call:
> PluginLoader::pluginForMime("text/html"). Though i still have to take
> a good look at that.
>
> But you're right, i can use the factory pattern here.
Ahh, I see. Personally I'd go with the following (pseudocode)...
Inside the PluginLoader constructor (or other method)
foreach (plugindir)
require plugindir/plugindir.php
$plugindir::init($this)
The static init() method calls PluginLoader::registerPlugin('mime/type',
'PluginClassName'). Then pluginForMime does a lookup for the mime type and
returns an object of the corresponding type. That way a single plugin can
support multiple mime types.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
I all,
I'm looking for a Class or a PHP bundle in order to programatically
fetch blog entries from a Dotclear Movable Type (MT) blog, with their
tags, categories, all available attributes.
I found http://goo.gl/JUbCN in order to almost do the job.
I could deal with it, but I'm looking for a more out-of-the-box thing.
Say for example,
$the_blog = new MTBlog($usr, $pwd, $url);
$tags=$the_blog->getTags();
$the_blog->getCategories();
$the_blog->getEntriesHavingTag($tags[3]);
Thank you, if you ever have that in your bookmarks.
--
RMA.
--- End Message ---
