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
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
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.
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.
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.
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?)
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!