December 5, 2014 in Feedback
As per a previously posted topic, I am using the suggested way to get member information about the currently logged in user so I can add integration between site and forums.
That part works just fine, but I found out today that $_GET, $_REQUEST, and $_POST are all being unset in the \IPS\Request constructor (after saving all variables to the class... only if not IN_DEV). This means anyone integrating IPS into their site without using Pages has one of two (main) options:
Unless I'm just not understanding something or not doing something correctly, I don't feel like a unset of those variables should be necessary. This is not done in the 3.X series. The code is only stripping out two characters (and undoing magic quotes). Is there any reason this unsetting of superglobals needs to be done now? Is this something that can be changed so a 'workaround' isn't necessary?
An example in case that did not make sense...
// Let's say the url is http://example.com/mycustompage.php?id=5
var_dump($_GET['id']); // Displays (int) 5
// Initialize IPS4 Framework
require_once( 'forum/init.php' );
// Indicate that we should consider this a front-end session so we can obtain the currently logged in users information.
// Grab the currently Logged In user.
$IPSMember = \IPS\Member::loggedIn();
var_dump($_GET['id']); // Displays NULL - Want it to still be (int) 5
var_dump(\IPS\Request::i()->id); // Displays (int) 5
Is there any reason you need to use the superglobals instead of \IPS\Request?
Initially I just found it odd that if we want to integrate IPS into our site, we are forced to rework our code. If the IPS code doesn't look at those variables again anyway, is there a need to remove them? I'm fine with them being unset if we're within the actual IPS Suite because I'm expected to follow your coding standard, but if all I want to do is grab and display a little information about the currently logged in member on my site, why do I need to alter the rest of my website's code to do that?
Third-party scripts would be the biggest issue I can think of, though. If one of those scripts is making use of any superglobal, then the end-user is now also having to dig around in code they likely wouldn't need to otherwise.
You're right. I'll change it
Thanks. Much appreciated.
This topic is now archived and is closed to further replies.
Started 4 hours ago
Started 2 hours ago
Started Sunday at 01:06 PM