Ravens PHP Scripts: Forums
 

 

View next topic
View previous topic
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> v2.4 RN Documentation
Author Message
killing-hours
RavenNuke(tm) Development Team



Joined: Oct 01, 2010
Posts: 438
Location: Houston, Tx

PostPosted: Sun Apr 10, 2011 1:34 pm Reply with quote

hey all-

Trying to integrate a 3rd party script with RN and hitting a road block at the moment. I'm trying require the mainfile in this 3rd party script so that I can use $db->sql_query however I'm getting the "failed to open stream" error back.

Is there a different method for adding the mainfile to other scripts?

_________________
Money is the measurement of time - Me
"You can all go to hell…I’m going to Texas" -Davy Crockett 
View user's profile Send private message
Palbin
Site Admin



Joined: Mar 30, 2006
Posts: 2583
Location: Pittsburgh, Pennsylvania

PostPosted: Sun Apr 10, 2011 2:09 pm Reply with quote

I am assuming the "failed to open stream" is referring to mainfile. It sounds like you are trying to include mainfile with the incorrect path.

_________________
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan. 
View user's profile Send private message
killing-hours







PostPosted: Sun Apr 10, 2011 2:24 pm Reply with quote

Yes, it's when I'm trying to include it so that the $db->sql_query function will be available for this script.

Without going into to much detail... I'm using uploadify in a project and the way uploadify work is by sending data to a php script. That script is going to do some stuff with the data that is send then it's going to do a database insert... however, I've tried adding

require('mainfile.php');

to the top of the script but I get the error. Have also tried a full path in that but returned an error page. (don't think I can do it that way for security purposes)

So I was wondering if there is some other way I should be attempting to require the mainfile.
 
neralex
Site Admin



Joined: Aug 22, 2007
Posts: 1772

PostPosted: Sun Apr 10, 2011 2:39 pm Reply with quote

...its a good question. my try to use this in external scripts ends withe same error.

exmaple:

nuke/ (root of nuke)
nuke/externalscript/index.php

if i try to use the mainfile require in my external index.php and set the correct path, then i become a error from the mainfile.php. config.php not found. wrong path of the config.php into the mainfile. is it a issue of the nuke document root settings? must i set my external script to this global document root?
 
View user's profile Send private message
killing-hours







PostPosted: Sun Apr 10, 2011 2:51 pm Reply with quote

Another piece of information, the script that needs the mainfile is a few layers deep in folders.

I.e.
Code:
modules/ModuleFolder/includes/jquery/uploadify/script.php


Not sure if that will help clarify any.

----------------

After testing this

Code:
require('../../../../../mainfile.php');


I get the same error as neralex

Code:
Response: <br />

<b>Warning</b>:  require_once(./config.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in <b>/home/xxxxx/public_html/mainfile.php</b> on line <b>147</b><br />
<br />
<b>Fatal error</b>:  require_once() [<a href='function.require'>function.require</a>]: Failed opening required './config.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in <b>/home/xxxx/public_html/mainfile.php</b> on line <b>147</b><br />
 
Guardian2003
Site Admin



Joined: Aug 28, 2003
Posts: 6799
Location: Ha Noi, Viet Nam

PostPosted: Sun Apr 10, 2011 4:07 pm Reply with quote

Interesting!
A lot of modules do the same thing i.e. require_once or include_once for mainfile.php so I cannot see how or where you would have an issue Sad
mainfile.php also includes config.php and should set the correct path - I presume your site is working every where else except within this custom module, so it could possibly be due to a redeclared variable accidentally over writing something but that's unlikely in RavenNuke (tm) as mainfile uses constant as path values and you would get a re-declared constant error.
I wonder of your server has open_basedir restrictions?
I'm curious though why you need to call mainfile from such a deep structure.
Would it not be easier to use the conventional approach of in modules/Your_Module/index.php
Code:


include_once 'mainfile.php';
include_once 'modules/Your_Module/includes/jquery/uploadify/script.php';


Also, you might want to try just ensuring $db is globalised
Code:
global $db;
in the script you are using; often times you don't even need to call mainfile, you just need to globalise $db and/or the $prefix or $user_prefix depending upon if you need those to match your database table names.
Don't forget to globalise inside any function as well Wink
 
View user's profile Send private message Send e-mail
killing-hours







PostPosted: Sun Apr 10, 2011 4:33 pm Reply with quote

I understand what you're saying Guardian... and I've had this issue prior but somehow it always seemed to work out. With this though... it's a bit different.

It's not that the module itself that is having the issue. Obviously the custom scripts for the module pass via the index.php which requires the mainfile then "globalizes" the $db, $prefix etc. However, within the module itself is a 3rd party script that DOES NOT pass through the index.php. It does however need the same functionality as the custom modules scripts ($db->sql_query) so that when the 3rd party script processes... it will flow naturally with the rest of the module.

So the way to think of this is a separate application WITHIN the module that needs the same functionality of the "normal" scripts.

I don't know of a better way to explain this without going way to far into the details... but that's the best way I can understand it.

P.s. Have tried:

global $db, $prefix
require('mainfile.php');
require_once('mainfile.php');
include('mainfile.php');
include_once('mainfile.php');
require(FULL_SITE_PATH.'mainfile.php');

What I don't get is when writing a regular module... you can start with a blank index.php and put require('mainfile.php') right at the top and it works perfectly... however, when trying to add the same thing to this 3rd party script... it can't seem to find the correct path. A bit perplexing but I'm sure it's something very simple I'm missing.

I have a feeling it's something to do with how the 3rd party script is seeing (or not seeing) the way RN handles the siteRoot. Just my .02

--------

Edit***

After re-reading this post... it occurred to me that the processing script of the 3rd party app. is not being passed via the "modules.php" and therefore wouldn't see the site root the same way... correct?

--------

This is how the uploadify takes the script path. It "should" be included as an op and called via that method if I'm following you correctly Guardian... correct?

Code:
"script"   : "modules/'.$moduleName.'/includes/jquery/uploadify/IadminUpload.php",


Since it's taking a direct path instead of passing via the modules php... it's never going to work otherwise.

-------------------

Final edit***

Thank you (yet again) Guardian for showing me the error of my ways. I can accomplish what I need by your suggestion. Been a long day and have been working on this project non for a few days now. Thanks!
 
Palbin







PostPosted: Sun Apr 10, 2011 6:30 pm Reply with quote

I see a lot of people talking about require_once 'mainfile.php'; being at the top of a lot of module files. This bit of code in almost every occasion is completely worthless. The reason for this is that mainfile.php has already been included by modules.php when it is calling your module. The only time you would need it is if your file is called directly, but has been shown before more than likely it will not work.

If anyone is interested in making the modifications to allow mainfile.php to be included when the calling file is outside of the site root do the following. Please note I have tested this, but at this time I can not be sure your site will work 100%. (need testers) Also note this changes should be in the next release of RN.

In mainfile.php find the following lines:
Code:


if(defined('FORUM_ADMIN')) define('INCLUDE_PATH', '../../../');
elseif(defined('INSIDE_MOD')) define('INCLUDE_PATH', '../../');
else define('INCLUDE_PATH', './');

Change to:
Code:


define('INCLUDE_PATH', dirname(__FILE__) . '/');


Lines 27-34 of includes/nukesentinel.php
Code:


// define the INCLUDE PATH
if(defined('FORUM_ADMIN')) {
   define('NSINCLUDE_PATH', '../../../');
} elseif(defined('INSIDE_MOD')) {
   define('NSINCLUDE_PATH', '../../');
} else {
   define('NSINCLUDE_PATH', './');
}

Change to:
Code:


define('NSINCLUDE_PATH', INCLUDE_PATH);


Lines 28-37 of db/db.php
Code:


if (defined('FORUM_ADMIN')) {
    $the_include = '../../../db';
} elseif (defined('INSIDE_FCKCONFIG')) {
    $the_include = INCLUDE_PATH.'db';
} elseif (defined('INSIDE_MOD')) {
    $the_include = '../../db';
} elseif (defined('INSIDE_INSTALL')) {
    $the_include = '../db';
} else {
    $the_include = 'db';
}

Change to:
Code:


$the_include = INCLUDE_PATH. 'db';


Line 37 of header.php
Code:


addCSSToHead(INCLUDE_PATH . 'themes/ravennuke.css', 'file');

Change to:
Code:


addCSSToHead('themes/ravennuke.css', 'file');


Line 55 of header.php
Code:


addCSSToHead(INCLUDE_PATH . 'themes/' . $ThemeSel . '/style/style.css','file');

Change to:
Code:


addCSSToHead('themes/' . $ThemeSel . '/style/style.css','file');


There are possible theme edits that may be required. You may get an error from the theme.php of your theme. If you do simply find the require/include in question and add INCLUDE_PATH to the beginning of it. For example require_once INCLUDE_PATH . 'themes/YOUR_THEME/tables.php';
 
killing-hours







PostPosted: Sun Apr 10, 2011 7:09 pm Reply with quote

Will setup a fresh testsite in the morning. Thanks for your time & effort Palbin!
 
Guardian2003







PostPosted: Sun Apr 10, 2011 11:27 pm Reply with quote

@ killling-hours, glad you got it working Smile
You just have to remember that the CMS has code in some of the core files that actually prevents some files being accessed directly. If it's administration, everything is controlled (processed / passed through) admin.php, everything else is processed/passed through modules.php
This is one of the reasons why stand alone third party code has to be 'ported'.
Of course there are work around's but personally, I wouldn't recommend them because there is always the risk that a cookie based session isn't being checked/handled correctly or there might be the potential for path disclosure/remote file inclusion, the anti-csrf token not being passed correctly through a form etc.

@ Palbin - I disagree with your 'fix'. When you have a square peg you have to fit in a round hole, you finesse the edges of the square peg till it fits; you don't just take a hammer and chisel to the hole because then everything that fitted in it before is now a sloppy fit (metaphorically speaking).
 
Palbin







PostPosted: Sun Apr 10, 2011 11:30 pm Reply with quote

Guardian2003, why would this make anything a "sloppy" fit? In my opinion it is all around better.
 
Guardian2003







PostPosted: Mon Apr 11, 2011 12:22 am Reply with quote

It just smacks of fixing something that isn't actually broken.
But, I know that won't satisfy you Wink so let's take a scenario....
dirname() doesn't like some high-endian characters from the utf-8 character set so potentially if someone was to install RN in a sub directory who's name contains one or more of those characters, it would fall over.
However (and in fairness) apparently the fix for that is to use setlocale() before using dirname()
The problem then becomes, which locale do we set using setlocale(). Do we use the servers locale (essential the 'default' since this is derived from server settings) or override the server locale and use the users locale (the site might be in Russian but hosted in the US as an example); will that then impact upon time/datestamps?
setlocale is thread safe on Apache/PHP but not with Windows/PHP where it is possible for locale to change on-the-fly (per process thread).
 
killing-hours







PostPosted: Mon Apr 11, 2011 7:34 am Reply with quote

Guardian2003 wrote:
@ killling-hours, glad you got it working Smile
You just have to remember that the CMS has code in some of the core files that actually prevents some files being accessed directly. If it's administration, everything is controlled (processed / passed through) admin.php, everything else is processed/passed through modules.php
This is one of the reasons why stand alone third party code has to be 'ported'.
Of course there are work around's but personally, I wouldn't recommend them because there is always the risk that a cookie based session isn't being checked/handled correctly or there might be the potential for path disclosure/remote file inclusion, the anti-csrf token not being passed correctly through a form etc.


Thank you again Guardian. The more I sat and slapped myself yesterday... the more you made sense in what you said. I wasn't tailoring this 3rd party script to work "WITHIN" Ravennuke. I also agree with your analogy (the peg). I, as a developer, should be focused on how to "port" in the 3rd party app rather than trying to get RN to adapt to it.

I'm still learning to be a coder... thanks for having patience & understanding with me. It really does help me a great and deal & I truly appreciate it. RavensScripts
 
Guardian2003







PostPosted: Mon Apr 11, 2011 12:53 pm Reply with quote

Well I'm still learning too but that's what I love about this community, we learn from each other. We learn more when we debate these issues than we can by poring over the PHP manual.
 
Palbin







PostPosted: Mon Apr 11, 2011 3:04 pm Reply with quote

Guardian2003 wrote:
It just smacks of fixing something that isn't actually broken.
But, I know that won't satisfy you Wink so let's take a scenario....
dirname() doesn't like some high-endian characters from the utf-8 character set so potentially if someone was to install RN in a sub directory who's name contains one or more of those characters, it would fall over.
However (and in fairness) apparently the fix for that is to use setlocale() before using dirname()
The problem then becomes, which locale do we set using setlocale(). Do we use the servers locale (essential the 'default' since this is derived from server settings) or override the server locale and use the users locale (the site might be in Russian but hosted in the US as an example); will that then impact upon time/datestamps?
setlocale is thread safe on Apache/PHP but not with Windows/PHP where it is possible for locale to change on-the-fly (per process thread).


We already define all our other constants in rnconfig.php via this way.

I also did a search and there are 255 hits for the use of dirname() in the pacakge. So I would call this a none issue as we have not had any issues that I am aware of. By the time this becomes an issues I would assume PHP would have this resolved.
 
fkelly
Former Moderator in Good Standing



Joined: Aug 30, 2005
Posts: 3312
Location: near Albany NY

PostPosted: Mon Apr 11, 2011 3:28 pm Reply with quote

I'll offer an alternative approach. I struggled for a long time to get ad-hoc database related scripts to run within Ravennuke. Usually they just read one or more of the tables and produce some output, they don't really need to be integrated. If they did I'd make them into modules or the like (even blocks perhaps) and follow the usual rules. But I don't need that for ad_hocs.

So what I did is:

set up an ad-hoc directory off the Ravennuke root.

set up a "simple_config.php" file in the root. All you need in it is the database parameters: something like:

Code:


$dbhost = 'localhost';
$dbuname = 'yours';
$dbpass = "your password";
$dbname = "your dbname";
$prefix = 'nuke';
$user_prefix = 'nuke';
$dbtype = 'MySQL';


all this can of course be copied from your working config.php.

then copy db.php and mysql.php from the /db directory of your distribution into your ad-hoc directory. Now you won't have to screw with paths.

Now in each program in your ad-hoc directory just do this at the top:

Code:


<?php
require_once('../simple_config.php');
require_once('db.php');


For most ad-hoc type programs all the other stuff in mainfile is unneeded anyway.
 
View user's profile Send private message Visit poster's website
Guardian2003







PostPosted: Mon Apr 11, 2011 5:13 pm Reply with quote

@fkelly, yes I have done similar things myself and I believe this is the correct approach. When you are writing code for a framework (I use the term loosely), whether it be RN, Drupal, Wordpress etc your code should be written to take advantage of that. If you need specific parts of the framework that are not normally available on their own, then you need to take a different approach with your own code to accomplish whatever you were trying to achieve.

Having said that, if there is a fundamental flaw in the design of the framework, then it's the framework that needs to be changed but I don't believe that is the case here. It hadn't occured to me to include db.php for the $db method, I tend to use my own abstraction layer class or just write normal queries because the existing layer doesn't support (as an example) mysql_fetch_object. It really depends on the needs of the code you are writing, how you are writing it and what is being used to process it. If you are writing code that isn't being processed through mainfile.php you lose user authentication, some useful data sanitisation, fckeditor etc - the really old (circa 2004) Nuke Treasury code is a prime example of that; include config.php, and hope it works.

As an off-topic aside, I'm surprised we have not yet replaced the $vars for the database connection in config.php with constants because then you wouldn't even need to do another remote include for config.php just to get the db connection data because it would already be in memory.
 
Raven
Site Admin/Owner



Joined: Aug 27, 2002
Posts: 17088

PostPosted: Mon Apr 11, 2011 9:16 pm Reply with quote

Guardian2003, you just mentioned something that I have been thinking about for a while -

* Changing our configuration settings to constants
* Pro's and Con's
* Should we do it

I was going to bring this up for a discussion with the Team but since you've broached the subject here, we can continue here if you all wish. The main advantage is exactly what you alluded to: Global access and variable (constant) protection as constants can't be changed.
 
View user's profile Send private message
Guardian2003







PostPosted: Tue Apr 12, 2011 3:09 am Reply with quote

I cannot think of any con's. Even though you cannot change constants once they are set (i.e. you cannot change them on the fly) you just write your code the same way you do for $vars; if it's True, do X or if it's False do Y.
I have a stand alone script that handles version messages, SQL and file updates for my CA brand modules and also my modules use stand alone installers so this is a great way for me to get the data I need, (include config.php once) then I 'bridge' those database settings by assigning them to constants so I can use them wherever I need to in my code.

For backward compatibility, we should probably leave the current DB connection vars in config.php and below them, re-assign them to constants and alter db.php to use the constants; I think that way, some older scripts with old style install routines (where they just include config.php) should still work (though it's debatable if we should really support such old code).

If we were to move to constants for 'settings' (read switches) my only real feedback would be that I think we should use a prefixing naming convention for all core settings with something e.g. SETTING_ to give us final reuslts like;
SETTING_WYSIWYG
SETTING_ERROR_REPORTING
etc.
This would make it a bit easier when using IDE's with code completion such as NetBeans, NuSpehere, Eclipse etc because we know that whatever it is we need starts with SETTING and don't have to rely on our memories to remember the full constant.
 
Raven







PostPosted: Tue Apr 12, 2011 5:53 pm Reply with quote

I've been thinking along the same line as we have had ongoing discussions about config files (the prefixing). I was thinking of something like RNCONFIG_ but the value is not important right now, only the concept.
 
Guardian2003







PostPosted: Wed Apr 13, 2011 3:50 am Reply with quote

Sounds good to me.
The next logically question, seems to be, do we want all our settings in one file?
It would seem to make sense that everything should be in one place because apart from the added security benefit (using constants instead of $vars) we are essentially doing this do make life easier for third party developers.
Doing so (keeping it all in one place) would also lend itself to something else we have discussed for a long time; distributing a settings file (e.g. config.php.inc) which has to be renamed to config.php (first time installs only) so for upgraders, there is no accidental over write of the settings file.
Of course there will be occasions when we add new settings, so the installer should give instructions on what to add or compare to the config.php.inc file.

Not wanting to complicate things or drone on too much but thought I would mention another benefit of having everything in one place.........
With a simple logic test (for either 127.0.0.0 or localhost), developers could run two different lots of DB settings in the same file allowing them to test development code on both a localbox and production environment simultaneously.
 
Raven







PostPosted: Wed Apr 13, 2011 4:17 pm Reply with quote

So little to do and so much time!?! - Strike that - Reverse it!!! killing me

I am still of the opinion that we won't reach true modularity unless/until each module/plugin/etc. (addons for short) can be added/removed from RN with little or no effect to/on any other part of RN which really requires each addon to have its own config file if required. The core config file and other core applications should not be touched unless there is absolutely no other recourse. Again, like the discussion above, my present thinking is along the line of "smart" prefixing for all permanent settings. In this context, "smart" refers to the naming convention for the prefixes. Without provoking a design discussion Laughing , a brief example could/would be something like the following:

PREFIX
RN_CFG_CORE_
RN_CFG_MODULE_
RN_CFG_NS_

These would only be used if/when the situation allows/requires it. In other words you would not need a config file unless the addon requires it. Actually, it might be easier if all modules had to have one, even if it's empty.
 
fkelly







PostPosted: Fri Apr 15, 2011 7:58 am Reply with quote

The problem is that, despite outward appearances and the presence of modules.php, generic or *nuke was never designed to be modular and there is at least a decade of code that implements non-modularity. So undoing that is going to be complicated and difficult.

To be modular there would need to be a database tables to modules relationship established, perhaps in config files, that all modules and the core would respect. A table would belong to core or to a module or be shared by multiple modules. But no code in any module would access any table that is not declared in a config file (or table) to be associated with it. And core code would not "presume" that any module is installed. There would always be checks to see if a table exists, or (same thing) if a module is installed, before accessing a table.

And we'd have to do some thinking about implicit dependencies between modules and between modules and core. Right now you can't install the product (RN) without Forums. Submit news depends on news. Comments assumes news exists. Mainfile assumes statistics exists. Stories archive and top depend on news being there. The search module searches other modules' tables. Topics depends on news which in turn depends on topics.

I know this is getting beyond the scope of the current thread of discussion. I just don't see us reaching true modularity any time soon. I don't see us reaching true modularity anytime period. Just improving the config file process as discussed by Guardian would be a big step forward.
 
Guardian2003







PostPosted: Fri Apr 15, 2011 12:31 pm Reply with quote

I don't want to drag this kicking and screaming so far off-topic that I lose what modicum of sanity I have but (as far as the design/theory goes) regarding Franks last post regarding modularity, I agree. It will reach the stage of true modularity (it has to), we just are not quite ready yet Smile

In all honesty, Submit News should really be part of/combined with News (something I have advocated since.. forever). You can utilise News without Submit News but not the other way around (well you could but it wouldn't make sense to do so). Submit News should *really* be a "plug-in" for News and by plug-in I mean code that allows user interaction with the module (subject to permissions) that it is installed in or to put it another way, something that extends the core functionality of the module.

By the same token, Comments (the module) could exist in it's own right (as an aggregation/moderation facility, which is what it is currently designed to do) but Comments could also exist as a "plug-in" (not the same code obviously) - to allow user interaction with each module it is assigned as a plug-in e.g. News Module comment plug-in, Reviews Module comment plug-in etc.

Regarding Top Module, that is fine as a module but the 'counter' should really be in footer, not mainfile, though strictly speaking it should be a 'plug-in' (despite the fact it wouldn't be DRY) for each module.

I better stop there.... Smile
 
Raven







PostPosted: Fri Apr 15, 2011 4:17 pm Reply with quote

RN v3.0 .... Not (necessarily) v2.5 Wink

But, I thought we had resolved the Forum dependency. What have I missed?
 
Display posts from previous:       
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> v2.4 RN Documentation

View next topic
View previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2007 phpBB Group
All times are GMT - 6 Hours
 
Forums ©