Stop disabling super globals

[sajaki]

i once backported the 3.2 ascraeus new request class into 3.0 to overcome the 3 levels limit of the 3.0 request class, and indeed, re-enabling the superglobals was necessary hackery afterwards.

[JWPlatt]

I just ran into this problem while trying to do some larger website integration on a site that also uses phpBB. The same shared code would be called by a phpBB extension and other website pages that have nothing to do with phpBB. Obviously, when someone is using a page that includes the shared code but has nothing nothing to do with phpBB, it won't have the request class available to call.

I tried imkingdavid's suggestion when calling from inside phpBB:

Code: Select all

$request->enable_super_globals();
$form->some_function_that_ends_up_using_a_server_variable();
$request->disable_super_globals(); 

I get this error in the apache log:

Cannot access empty property in ...

Do I need to add access a global somehow? What's the code to let me use the $request class?

Suggestions?

[JWPlatt]

I fixed this by using "global $request;" to get the web root path which is what I needed:

Code: Select all

    <!-- PHP -->
     global $request;
     $request->enable_super_globals();
     $myroot = $request->server('DOCUMENT_ROOT', '');
     $request->disable_super_globals();
    <!-- ENDPHP -->

I first tried to instantiate a new request class, but that got errors.

These things are either not well documented or not easily found within the documentation when you don't know what to look for. For example, it would be nice to easily find a list of globals such as $user and $request in the context of needing help while doing site integration of which phpBB is only a part.

I've found a lot of people with problems like these in my searches, and they are seemly universally trying to integrate phpBB across a site. I come away with an impression that the vision of phpBB's development isn't holistically aware enough, and that maybe it doesn't don't care to be. I'd like to see phpBB aim at site integrators a lot more. I don't want to learn the platform to use or integrate the product. But by the way, MediaWiki is even more self-satisfied - i.e. difficult. phpBB is at least more flexible. The ability to easily wrap a forum or a wiki into an overall site banner and navigation as a solution and have them play nice would be a welcome relief. This is really too hard. Things should be so easy to do what you want across a site that my clients wouldn't need me to achieve the arcanery.

[DavidIQ]

This was discussed before on phpBB.com and is pretty easy to implement and does not require any code edits. Just needs more proper or official documentation somewhere.

[JWPlatt]

Thanks, I skimmed through it.

One statement is not provided in that thread that an integrator probably needs (I did):

Code: Select all

global $request;

There is a heavy assumption of familiarity with the platform, which is why I hope phpBB can consider making things easier for integrators.

This has been a long road of days of searches for good answers after I tried to use a naked $_SERVER[]. I found pieces, and usually old info as I guess you noticed, but never a complete code sample. So now, for example, I thought I had a proper solution after a lot of time spent on finding what I found was the recommend solution. The thread you linked me to offers what appears to be a more acceptable solution. But it does not do one very important thing for someone who does not want to learn the phpBB platform to get their integration job done:

A full code example of the recommended way to get $_SERVER[DOCUMENT_ROOT] and use it to include() a PHP script somewhere else and documentation of the hows and whys.

I've also had a difficult time calling external scripts from within a phpBB subdomain to use shared php/css/image assets stored in folders in the real (non-subdomain) document root. It's a much longer story. The gist of it boils down to something I will put in a feature request, if I get a chance, to have ACP fields/variables for entry of a domain name (I can't find a phpBB variable for that!) and the web root server path ($_SERVER[DOCUMENT_ROOT] is unusable in the case of subdomains) so that they can be used in the HTML CSS links and so forth within phpBB HTML files without escaping into PHP at all. In addition, maybe even make all the $_*[] superglobals available in your {} variables.

Thanks.

[DavidIQ]

The gist of it boils down to something I will put in a feature request, if I get a chance, to have ACP fields/variables for entry of a domain name (I can't find a phpBB variable for that!) and the web root server path ($_SERVER[DOCUMENT_ROOT] is unusable in the case of subdomains) so that they can be used in the HTML CSS links and so forth within phpBB HTML files without escaping into PHP at all.

Something wrong with the Domain Name server setting in the ACP? These settings are loaded in the $config array available throughout phpBB. There is even the generate_board_url() function in use in quite a few places in the core code.

In addition, maybe even make all the $_*[] superglobals available in your {} variables.

The request class should have pretty much everything you'd need.

[JWPlatt]

Good hints. I'll check it out and get back to you. But I'll say in advance that I do want to avoid needing to use the PHP/ENDPHP comment tags.

Is there good documentation somewhere about how to use, and what's available with, the $config array, and how generate_board_url() is used?

I'll add that these things look to be demanding that I get more familiar with the phpBB platform, something I've mentioned is not a positive.

[DavidIQ]

You don't have to be intimately familiar with phpBB but you must have knowledge of both PHP and MySQL to make reasonable assumptions from looking at the code.

The contents of the $config array aren't going to be listed anywhere reliably because this list can vary from forum to forum. Therefore you just need to look at the phpBB config table to know the contents of the array, which is basically whatever is in that table (config_name column). generate_board_url is defined in the functions.php file I believe so looking at it there and the comment block above it will give you the information you would need on what it can be used for and how.

[JWPlatt]

Something wrong with the Domain Name server setting in the ACP?

The server domain name isn't what I need. That field contains the subdomain the forum is on: forums.domain.com. I need the main domain name where the shared code files are held in a folder: www.domain.com/shared_code (/home/user/www/shared_code). There is currently no field I know of in phpBB on a subforum that offers "www.domain.com" instead of "forums.domain.com". Nor is there a value that directly offers the web root address of "/home/user/www" instead of "home/user/www/forums" on a subdomain as I mentioned above about $_SERVER[DOCUMENT_ROOT]. Those two custom values, and a way to include them in html scripts and get at their values from php would be greatly helpful. If I could set these custom values in the ACP, that would be fantastic. I don't see where to do that.

Above, I had this code sample:

Code: Select all

<!-- PHP -->
     global $request;
     $request->enable_super_globals();
     $myroot = $request->server('DOCUMENT_ROOT', '');
     $request->disable_super_globals();
    <!-- ENDPHP -->

You mentioned there was a better way to achieve this in this discussion. I know you're saying the information I need is there, but it's in pieces and I just can't put it all together. Can you give me an equivalent code sample based upon that discussion?

Also, can you give me, or point me to, a code sample of how to use the $config array?

I haven't looked at generate_board_url() yet, but I will asap.

In addition, maybe even make all the $_*[] superglobals available in your {} variables.

The request class should have pretty much everything you'd need.

I was prevented from using the $request class for what I need unless I use enable_super_globals(), as above, but that thread you pointed to says I should never do that (so why provide it?). Further, there is no $request class variable that can give me the main site document root instead of the subdomain document root.

Thanks for the help. Much appreciated.

[DavidIQ]

The server domain name isn't what I need. That field contains the subdomain the forum is on: forums.domain.com. I need the main domain name where the shared code files are held in a folder: www.domain.com/shared_code (/home/user/www/shared_code). There is currently no field I know of in phpBB on a subforum that offers "www.domain.com" instead of "forums.domain.com". Nor is there a value that directly offers the web root address of "/home/user/www" instead of "home/user/www/forums" on a subdomain as I mentioned above about $_SERVER[DOCUMENT_ROOT]. Those two custom values, and a way to include them in html scripts and get at their values from php would be greatly helpful. If I could set these custom values in the ACP, that would be fantastic. I don't see where to do that.

There isn't a way to do that through the ACP so you'd have to create yourself a simple extension that feeds that to the template variables. There are quite a few extensions that do this but you can check how it's done in this one and do something similar:

Above, I had this code sample:

Code: Select all

<!-- PHP -->
     global $request;
     $request->enable_super_globals();
     $myroot = $request->server('DOCUMENT_ROOT', '');
     $request->disable_super_globals();
    <!-- ENDPHP -->

You mentioned there was a better way to achieve this in this discussion. I know you're saying the information I need is there, but it's in pieces and I just can't put it all together. Can you give me an equivalent code sample based upon that discussion?

Your code is fine as is but if you wanted to enable super globals globally you'd want to go the parameters.yml route. Otherwise you can stick to the above.

Also, can you give me, or point me to, a code sample of how to use the $config array?

Same way you'd use any other PHP array: $config['whatever_config_key']

I was prevented from using the $request class for what I need unless I use enable_super_globals(), as above, but that thread you pointed to says I should never do that (so why provide it?). Further, there is no $request class variable that can give me the main site document root instead of the subdomain document root.

Thanks for the help. Much appreciated.

The statement that using $request->enable_super_globals() is not recommended is not really very accurate. It can be used as needed but to enable super globals globally the better route is to use parameters.yml.