How do I call a php page that can use the includes if its stored in plugins/

[donnoman]

I'm trying to make minicms a plugin, and I'm obviously missing something.

I wanted to keep all the files self contained down in the plugin folder.

There are two pages that were built to administer the cms system, I moved them from the root of the gallery to the plugin dir.

/gallery/plugins/minicms/cms_admin.php
/gallery/plugins/minicms/cms_edit.php

However I can't include init.inc.php even if I use the right relative path.

require('../../include/init.inc.php');

Warning: main(include/debugger.inc.php): failed to open stream: No such file or directory in c:\inetpub\wwwroot\develcms\include\init.inc.php on line 26

Fatal error: main(): Failed opening required 'include/debugger.inc.php' (include_path='.;c:\php4\pear') in c:\inetpub\wwwroot\develcms\include\init.inc.php on line 26

I can see why this is happening, but other than moving those files to /gallery I'm not seeing a way around it.

I don't see how I can use filters to prevent the rest of a regular coppermine page shown, and insert my own. (or even if that would be an acceptable way if I could).

I'm thinking perhaps I could put a placeholder .php file out at the root of the gallery and do something like this:
plugin.php:

Code Select Expand


<?php

define('IN_COPPERMINE', true);
require('include/init.inc.php');

// if no plugin is specified then abort, don't let plugin writers get sloppy
// Plugins use the 'plugin_full_page' filter and examine the passed variable
// to see if its for them.
if (isset($_GET['plugin']))
$plugin = (int)$_GET['plugin'];
elseif (isset($_POST['plugin']))
$plugin = $_POST['plugin'];
else
    cpg_die(CRITICAL_ERROR, 'No Plugin Specified', __FILE__, __LINE__);


$data=CPGPluginAPI::filter('plugin_full_page',$plugin);

// If no $data was returned then no point in proceeding any further, something is wrong.
if (!$data) cpg_die(CRITICAL_ERROR, 'No data returned from plugin!', __FILE__, __LINE__);

pageheader($data['title']);
echo $data['content'];
pagefooter();
ob_end_flush();
?>

At that point your plugin could act on all the superglobals, do its work, and then return an array with the output. And it's generic enough it could work for any plugin who needed to do something similar.

Thoughts?

[donnoman]

This is the exact one I have working:

Code Select Expand


<?php

define('IN_COPPERMINE', true);
define('EDITPICS_PHP', true);
require('include/init.inc.php');

// if no plugin is specified then abort, don't let plugin writers get sloppy
// Plugins use the 'plugin_full_page' filter and examine the passed variable
// to see if its for them.
if (isset($_GET['plugin']))
$data['plugin'] = $_GET['plugin'];
elseif (isset($_POST['plugin']))
$data['plugin'] = $_POST['plugin'];
else
    cpg_die(CRITICAL_ERROR, 'No Plugin Specified', __FILE__, __LINE__);


$data=CPGPluginAPI::filter('plugin_full_page',$data);


// If no $data was returned then no point in proceeding any further, something is wrong.
if (!$data) cpg_die(CRITICAL_ERROR, 'No data returned from plugin!', __FILE__, __LINE__);

pageheader($data['title']);
echo $data['content'];
pagefooter();

?>


It hosed up htmlarea pretty good, though I've got some of the functionality back. It will just take time to carefully go through and re-hardcode the path to plugins/minicms/htmlarea ....

[omniscientdeveloper]

That way seems kind of clumsy.

I just modified index.php (moving some plugin code around), so you can do "?file=" and it'll include a file into the index page, skipping all the other stuff.

I'll test it out some here and commit it later today.

[donnoman]

I didn't say it was pretty... I just said I got it to work  

[Tranz]

Okay, so it's not just me. I was trying to do the same thing today (include init.inc.php in a gallery subfolder) and got the same error. So now I understand donnoman's question and eagerly await omniscientdeveloper's solution.

[omniscientdeveloper]

I'll be able to test my changes in a couple hours, so I'll commit it (for sure) today.

[omniscientdeveloper]

My changes have been committed.

Calling the index.php page with the file parameter will load a page into coppermine. The constructed URL should look like: index.php?file=plugin_folder_name/file. See the example.

index.php?file=mypluginfolder/messages

The above will load the page "messages.php" from the "mypluginfolder" inside coppermine's plugins folder.

NOTE: You'll also have to execute the pageheader and pagefooter functions, in your file, if you want the actual template to show.

I think a logical course for this, later, is to modify the UDB files so they can be included into a seperate application thereby allowing you to use it's authentication methods. I'll do this in 1.5.

[donnoman]

Are we opening up a security hole here that can be used for injection attempts and/or cross site scripting?

I haven't had a chance too look at the code, but this looks risky.

[DJMaze]

it's easy use fullpath includes which is better anyway:

for example but in init.inc.php the following:

Code Select Expand


if (!defined('GALLERY_DIR')) {
    $root_path = dirname(dirname(__FILE__));
    if (strtoupper(substr(PHP_OS, 0, 3)) == 'WIN') {
        $root_path = str_replace('\\', '/', $root_path); //Damn' windows
    }
    if (strlen($root_path) > 2) define(GALLERY_DIR', $root_path.'/');
    else define('GALLERY_DIR', '/');
}

Then each file that does a include uses:

Code Select Expand

require_once(GALLERY_DIR.'my_file.php');

That way it doesn't matter how deep the rabbit hole goes........

[omniscientdeveloper]

There's no way to include a file outside the plugins folder. The things that I took care to block were:

1. Files being included from outside the plugins folder.
Done by removing and ".." from the path and prepending the "./plugins/" string.

2. Non-PHP files being included.
".php" is added to the end of the string, so it'll only include php files (stored on the server).

If you wanted to include a non-php file, you could include it with code in the plugin file.


You guys can try to break it. If you're successful then we'll have to rethink the code a little, but I can't see that happening.

[donnoman]

@omni next difficulty.

Since init.inc.php has already been called, the defines are being ignored in the called files, so grabbing lang arrays that aren't default is going to be a problem. Any ideas?

[omniscientdeveloper]

I don't understand.

[donnoman]

Nevermind, I'm going to need to provide my own language file for the mod. Not a problem.  It was a kludge anyway.

[Joachim Müller]

I got this by PM:

Hi,

I tried to post this to the 1.4.x testing board, but obviously only developers can post to that.

I was looking at plugins and thinking of the possibilities for this. It seems to me that some plugins will certainly want to have their own pages, which either replace or augment existing pages. One of my ideas was a replacement picture editor popup. A problem I see is that these will undoubtedly need to access the include/init.inc.php file. This file then references debugger.inc.php and config.inc.php. This is fine if you are calling it from the root directory of the site, but if your file is residing in the /mysite/plugins/myplugin directory, the references to debugger.inc.php and config.inc.php will look for the files in /mysite/plugins/myplugin/include.

The solution would seem to be to store a constant in the system for the physical path to the main coppermine directory. All include/require statements would then be in the form:  include COPPERMINE_ROOT_PATH . '/include/init.inc.php' etc.

Apologies if this has already been resolved in another way.

Best wishes

Jeff Paffett

@Jeff: thanks for your feedback, so far this has not been discussed yet afaik. In the future (while the cpg1.4.x board is locked for "regular" users in terms of starting new threads), please post cpg1.4 bug reports on any other board that you can think of (i.e. the cpg1.3 support board) - a moderator will move it here if applicable (as long as it is obvious that you're reporting a devel version issue)

Joachim

[omniscientdeveloper]

I got this by PM:

LOL....So did I.


I just hadn't responded yet, because it's invalid....

If you use index.php?file=plugin_path/file_minus_php_extenstion (index.php?file=sample/somefile), to call additional files in a plugin, all the basic includes he's speaking of will be included.

*Merged the two related topics*

@gaugau: We may need a plugins subboard under the 1.4 board when it's created. Maybe we should start putting it together now and move/post threads there.

[Joachim Müller]

@gaugau: We may need a plugins subboard under the 1.4 board when it's created. Maybe we should start putting it together now and move/post threads there.

Did as you suggested - I created the whole cpg1.4 support board structure in advance, plus an additional sub-board named "plugins". The new support board (and all it's child boards) are currently only visible for dev team members.
If you (or any other dev team member) could think of a better naming scheme, board description etc. or if you want other sub-boards to be created, please let me know.

Joachim

[jpaffett]

Thanks for the feedback on this.

I tried the solution created by omniscientdeveloper and while it works it does mean you have to hard code long paths for includes in the plugin. I think the solution suggested by DJMaze would be more robust for the future.

Jeff

[omniscientdeveloper]

I don't understand what you're talking about! 

If you have to include a file within the plugin use:

$thisplugin->fullpath which points to the directory of the plugin executing at the time


If you need a file to be executed, with all the basic coppermine includes then use:

index.php?file=pluginfolder/file to call it


With both of these methods, there isn't any need to actually know where the coppermine include folder is, since it's all done for you. Like I said, I don't understand what you're talking about....

....You'll have to explain, in detail, what you're trying to do.