Bring PHP outside variables to PHP class?

I have a php class code:

include("auth.php");



$user = mysql_result($res, 0, "id");    

 class qqFileUploader {
    private $allowedExtensions = array();
    private $sizeLimit = 10485760;
    private $file; 

etc code continues… using inside the class:

$user=$user;  ///$user returns nothing "" 
////GET command seems to work like $test=$_GET['test'];

How can I get the $user variable to work, so I can access it inside the class, get the results from mysql db.

public $user; or private $user; is not working

How do you bring outside generated variables inside the class, this is getting so confusing?

Thank you

I think you want to use $GLOBALS[‘user’] to access the global $user
But, global state is bad in OOP Theory.
Just pass your $user as a parameter of the method that use the $user

1 Like

Thank you for the globals attribute, that works(“nothing is perfect”), but the second suggestion is unclear, seems a lot more work.

You might want to consider a complete re-write of the class, the old mysql_* extension is deprecated in version 5.5 of PHP and is being removed in version 7 of PHP. You need to be using either the mysqli_* extension or PDO

yes I am on php 5.4, (5.5 needs the mysqli upgrade etc) so I hope to be on this version for the next “2 years”, before I need to rewrite entire 100 pages of php code… currently I am updating not rewriting everything… sounds right? cheers

That’s a reasonable approach. No need to rewrite code until you have the time or you absolutely need to because it breaks.

As you are now rewriting this code anyway now is the perfect time to migrate away from the DEPRECATED mysql_ functions.

Many prefer PDO, but maybe you would prefer changing to the mysqli_ functions instead?

Do you know for certain that the code will always and only ever be working with MySQL ?

How much control do you have over what version of PHP is installed on the server?

Via composition either as a constructor parameter, setter or method parameter (if only the method relies on the user dependency and not the entire inner workings of the class).

// method 1: Y class relies(depends) on $user
$x = new Y($user);

// method 2: Commonly referred to as "setter injection". Works best for a DIC (dependency injection container)    //and alternate "constructor" that is called automagically after dependencies are resolved via injection.
$x = new Y();
$x->setUser($user);

// method 3: Y::doSomething relies on user but *most of class does not.
$x = new Y();
$x->doSomething($user);

As for globals I’m not going to waste my time telling you to avoid them as there are numerous resources available for that. Search on google for “why are globals bad” and you will be provided with the information. Here is one result.

http://tomnomnom.com/posts/why-global-state-is-the-devil-and-how-to-avoid-using-it

I very much doubt that PHP 5.4 will still be supported at all in 2 years time. You have already had 5+ years since the removal of mysql_ support was announced so you ought to be very near the end of the process by now.

Anyway of you are converting from mysql_ to mysqli_ then you can do a global replace to take care of most of the changes required so any site can be converted in an hour or two at most.

It is the conversion from query() to prepare()/bind()/execute() and the conversion to use the OO versions of the calls to bring the code ruight up to date that take the most time. The actual switch to mysqli_ is trivial until you are ready to implement the new features and better security that the newer interface provides.

The question really comes down to whether the op has ownership over the codebase or has been contracted to do specific work. If the former than it would be wise to consider replacing mysql_* functions with PDO or better yet a object-oriented database abstraction layer. Otherwise it isn’t the ops responsibility to update the codebase if that is not the job he/she was contracted to complete. All to often people are quick to assume postings are from people whom own the codebase rather than contractors who are merely paid to do specific jobs. As a contractor it might be wise to recommend an update but far to often people don’t want to pay for things they can’t see.

If is still a good idea for them to advise that the current codebase contains obsolete code that will not work for very much longer so that the owner can start thinking about getting that code rewritten (if they haven’t already made such arrangements).

In this particular case the need to make these updates was first advised in the standards quite a few years ago and so a significant portion of the time available to make the updates before the commands are deleted has already passed. It would therefore be irresponsible for those answering questions about such code if we were not to point out that thise commands need replacing sooner rather than later if the code is to continue working (even if the person asking the question isn’t responsible for the entire codebase).

Who will the owner blame if shortly after a contractor’s changes are implemented the PHP version gets updated and the antiquated SQL calls stop working?

Yes, if the client makes the informed decision to pay a bit less now and more again soon rather than pay a little bit more now and none later, that’s their decision to make.

Agreed. If the dev doesn’t want to get hung out to dry, inform the client.

Considering how long it has taken for most well known shared hosts to move from <=5.2 to >=5.3 I don’t think that is a realistic scenario. It is going to be several years before shared host move to 7 if at all. The option that makes more sense would be to offer servers with 7 while keeping all the other intact at least for a few years time.

At that point you would just inform the client that the code predates the work which was completed by yourself.

Best to advise the client now so that they have time to decide how they want to deal with it.Hopefully they would already have decided when to action it as they should have been advised by the first contractor to work on their code after they were upgraded to PHP 5.0 (when it was announced that the mysql_ interface was going to be discontinued) but better now than after their system fails.

2 Likes

The script is in the shared hosting server, so they keep updating PHP, and you can select the version you would like currently the max is 5.5 or 5.6, but they never deprecate a current version I am using(they just add a note “old” or something), one of the servers is using PHP 5.2(it is still working, but once I change the version to newer one I can’t change it back to the old version), current oldest one is 5.4 that I can select, so I think it will last 2 year, this is the time I need or something like that. I also added php 5.4 to my VPS.

MySQL(i) etc functions != time efficient.

About PHP Globals, I really don’t use any PHP classes like that, written completely inside my code, never used it, just some good function was written I liked. So it’s pretty unfamiliar to me.

Anyways I don’t think that global attribute($GLOBALS[‘vars’]) is that bad it does what I want and you can not interrupt and “infect” my code just like that, it can not be overwritten by the user(at least if it’s specified by the server), so am I right or am missing the point here…

and I shouldn’t use $_GET and $_POST too? (how should I get the ajax request?)

Thank you!

There isn’t really any valid reason for any server to still be using 5.2, as 5.2 reached the end of its life nearly 4 and a half years ago.

http://php.net/eol.php

No site should rely on any of the versions listed there.

Well, the user can’t overwrite the GLOBALS, but other developers could in other areas of the codebase, which is why globals are generally frowned upon. You could/should just do the SQL query inside the class itself, rather than outside and pulling it in.

Also, ditto on what everyone said about upgrading to mysqli.

You are right , use global attribute only if there is no other “reasonable” way… mysqli is in my “to do list”, but at the end of it, it’s like “100” pages long. cheers!

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.