1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

PHP 7.0 What? & When is production?

Discussion in 'PHP' started by dmvictoria, Nov 29, 2015.

  1. #1
    I heard it was supposed to happen sometime next year. But, I can't find the timeline any more.

    I'm just wondering when you will consider (7.0) the "common version" like 5.6. is now.

    Fantastic promises' of speed and efficiency... got me tantalized.

    You?
     
    dmvictoria, Nov 29, 2015 IP
  2. Helge Sverre

    Helge Sverre Prominent Member Affiliate Manager

    Messages:
    840
    Likes Received:
    99
    Best Answers:
    2
    Trophy Points:
    305
    Digital Goods:
    2
    #2
    According to PHP.net, PHP 7 is due to reach "General Availability" on December 3rd.

    You can find the timetable here: https://wiki.php.net/todo/php70#timetable
     
    Helge Sverre, Nov 30, 2015 IP
    dmvictoria likes this.
  3. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #3
    I'm just waiting to sit here giggling and laughing at all the dipshits who are going to run around like chickens with their heads cut off since mysql_ functions simply don't even EXIST in 7.

    A LOT of outdated crap is being kicked to the curb, but I suspect much like PHP 5 and 4, we're going to see morons, idiots and fools trying to run the latest 5 alongside 7 instead of FIXING THEIR OUTDATED BUG RIDDEN CRAP!

    JUST like how hosts ran 4 alongside 5 out of ignorance, apathy and wishful thinking.
     
    deathshadow, Nov 30, 2015 IP
  4. PoPSiCLe

    PoPSiCLe Illustrious Member

    Messages:
    4,623
    Likes Received:
    725
    Best Answers:
    152
    Trophy Points:
    470
    #4
    I wouldn't hold my breath. Most hosts won't change to 7 the first ~5 years, simply because it will render a lot of code unusable. Fact of life. I'm hoping my host will at least offer a PHP 7 hosting possibility. Which reminds me I was gonna send them an email about that..
     
    PoPSiCLe, Nov 30, 2015 IP
  5. redesignunit@gmail.com

    redesignunit@gmail.com Banned

    Messages:
    230
    Likes Received:
    5
    Best Answers:
    0
    Trophy Points:
    108
    #5
    in upcoming days almost all host need to offering support of php 7 support because stability and fast speed need of current market.
     
    redesignunit@gmail.com, Nov 30, 2015 IP
  6. PoPSiCLe

    PoPSiCLe Illustrious Member

    Messages:
    4,623
    Likes Received:
    725
    Best Answers:
    152
    Trophy Points:
    470
    #6
    Are you dense? There are STILL quite a few hosts running php 5.3 or 5.4 - 7 isn't gonna be a selectable option, even, until there's requests for it. People aren't gonna pay out the nose to update outdated code as long as it works on the current version. It's the sad truth.
     
    PoPSiCLe, Dec 1, 2015 IP
  7. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #7
    Another reason I don't go with managed or shared hosting; I can install whatever the **** I want, whenever the **** I want.

    Unmanaged VPS or dedicated, to blazes with anything else. I can do what I want, and short of a hardware failure the only place I can put the blame when things go wrong is on myself. I hate being at the whims, preferences or requirements of others.
     
    deathshadow, Dec 1, 2015 IP
  8. PoPSiCLe

    PoPSiCLe Illustrious Member

    Messages:
    4,623
    Likes Received:
    725
    Best Answers:
    152
    Trophy Points:
    470
    #8
    Well, yes, I agree on that, I do, but I really can't be arsed keeping up to date on managing a server myself. It takes too much time, and involves too much log-reading, tinkering and stuff I have no patience for anymore. Currently I'm running several servers for different projects, although most are with one hosting company, and most of them are either on a shared/semi-managed system. I think maybe I have one or two "dead" VPSes (dead in as I don't use them for anything, and they probably haven't been updated for anything for a couple years - I'm not even sure they're still active).
     
    PoPSiCLe, Dec 1, 2015 IP
  9. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #9
    Apart from major upgrades I don't see it taking a slew of time unless something really goes wrong -- which usually doesn't happen.

    But then I'm a Debian guy; apt-get to the rescue. Once a month just apt-get update, then a apt-get upgrade install...

    Things like logs, only dive into that if something seems off in webalizer, well apart from a once every few months check that the error logs aren't going crazy; developing or deploying new software you should do that anyways managed or not; it's not like your software's errors mean jack shit to some "sleaze out a thousand hosting accounts a week" host.

    Though I did have a headache this last bout of updates; for some reason couldn't connect to the main repositories, had to configure it to use a mirror -- oh noes, not that.
     
    deathshadow, Dec 1, 2015 IP
  10. qwikad.com

    qwikad.com Illustrious Member Affiliate Manager

    Messages:
    7,151
    Likes Received:
    1,656
    Best Answers:
    29
    Trophy Points:
    475
    #10
    @deathshadow since you're fluent / flexible in so many programming languages do you have a pretty good grasp of what php 7 requires code-wise? I mean can you already write codes up in php 7 from scratch?
     
    qwikad.com, Dec 1, 2015 IP
  11. ketting00

    ketting00 Well-Known Member

    Messages:
    772
    Likes Received:
    27
    Best Answers:
    3
    Trophy Points:
    128
    #11
    How PHP 7 supposes to be faster than the current version? Is it compile or interpret code faster?

    I guess an early adopter will have to install it manually when it come out, isn't it.
     
    ketting00, Dec 1, 2015 IP
  12. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #12
    It's really a non-issue; I abandoned pretty much all the bad practices from PHP 4 they have made not work, the handful of things that are in-between I really never used as I saw no point, and it's not like they don't have perfectly good guides on the differences.

    The big things to look for compared to PHP 5.x is first the "backwards incompatibilities"

    http://php.net/manual/en/migration70.incompatible.php

    Let's go down that list...

    Internal constructors behave like user constructors - ABOUT time, just makes debugging easier. If you were relying on how system classes were bombing in your code, you were doing something wrong.

    Parse now throws parse errors -- So we can trap and better diagnose them or log them ourselves... Again, that shouldn't break well written code.

    E_STRICT notices severity changes -- Again more verbose error handling, just makes fixing crappy code easier. If you don't HAVE crappy code this doesn't effect you!

    Changes to indirect variables -- if that evaluation order was actually important in your code, your code was probably too damned complex for it's own good. Again, a non-issue if you have ANY clue what you are doing.

    Changes to list() handling -- *YAWN* I rarely if ever use list in the first place as it's a complete waste of memory to create copies as "variables for NOTHING" -- it's sloppy code I'd never have had in the first place!

    PARTICULARLY in a language that has perfectly good associative arrays!!!

    Array assignment order -- Generally if you are referring to self by reference there's something wrong.

    Parentheses around function parameters no longer affect behaviour -- again, PROPER error handling. If this throws an error in your code, your code is rubbish.

    Changes to foreach -- I wasn't aware that it even used the internal pointer, but then I never trusted the internal pointer on arrays to begin with. Another of those things that if you needed to rely on it there was likely something wrong with your code.

    By value is now sandboxed with a copy -- wasteful of memory but the correct behavior... By reference now properly passes it. Really this is just cleaning up PHP's sloppy variable typing, scope and that it tries to behave like a language that has pointers when it doesn't.

    "traversable" -- is so poorly documented I never used it.

    Integer Handling

    Oh look, they fixed Octal... this is 2015, who the **** is using Octal? Are there STILL people working with talking to DEC and WANG hardware or something?

    Negative shifts -- would be nice if it did the opposite shift, but throwing an error would be the correct behavior.

    "out of range" is now platform independant -- that's a good thing; no more headaches of "is this shift going to chop off at 32 bits or 64 bits?"

    Divide by zero now returns the appropriate value instead of false. Big deal, that's still a warning level item that your code shouldn't have done in the first damned place!

    String handling

    Auto-conversion to numeric of hex was actually kind of nice, but not something I'd have relied on. Realistically this is just an artifact of how ****Tarded it is to have a programming language without strict typecasting -- as such not something I'd ever worry about.

    .. and of course now that \u can do unicode, \u in a string could trip an error... laugh is just use singles and \u won't be processed as the only valid escape sequences in singles is \' and \\ -- just another reason single quotes should be the preferred string method and doubles only used when you absolutely positively need escape sequences!

    Removed functions -- I stopped using the deprecated from PHP 4 crap so 90% of this doesn't even affect me. I dislike mcrypt so *YAWN*, "magic quotes" is idiotic outdated bullshit that never should have existed in the first place, loading extensions at runtime was dumbass nonsense, and the loss of Postscript support in GD is fine, I never used that either.

    Removed INI directives All stuff I never used and saw no reason to use.

    Other changes -- new objects by reference has been throwing deprecated warnings for a DECADE, so again not something I ever would have used... they are enforcing reserved words better I'm all for that...

    They axed the stupid ASP style crap, shame they didn't also axe <?php and ?>, but they'll get to that some day.

    Context tightening is again somethign that was deprecated and we as PHP dev's should already have been doing.

    They tightened up yield handling, a new feature that's absolutely badass... but so new changes should be expected.

    Why the hell would it have allowed parameters with the same name in the first place? That's a herpafreakingderp fix.

    Same goes for multiple defualt blocks in switch/case. Why was that allowed in the first place?

    $HTTP_RAW_POST_DATA -- global var crap that shouldn't have existed in the first place.

    Semi-colons instead of # as comment starts in INI files -- YAWN.

    JSOND instead of JSON, which means stricter handling of values, mostly relating to re-re invalid/nonsensical use of decimal points. That's a bugfix, not a deal breaker.

    Function failure on overflow -- GOOD, silently chopping off string to numeric conversion was jacktarded nonsense.

    Custom session handler return values -- now that since PHP 5.3 the normal session handler isn't banjaxed destroying sessions every time the wind blows, I've not needed to use custom handlers.

    Then you need to look at deprecated features.
    http://php.net/manual/en/migration70.deprecated.php

    PHP 4 Style Contsructors -- never used them. PHP 4's pathetic attempt at implementing objects may have had something to do with that. Oh noes, use __construct.

    Static calls to non-static methods -- IMHO this should throw an error, not a warning. Again, idiotic nonsense you shouldn't do in the first place.

    no user salt on password_hash -- Not that I use it in the first place, I prefer good old hash() with either sha256 or sha512

    Besides their internal hash has the problem of not being portable, you move to another machine the "secure" hash is different and everyone's accounts break -- another reason I don't use that in the first place!

    capture_session_meta SSL context option -- again, just removing a redundancy on something I rarely look at.

    Then some functions changed:
    http://php.net/manual/en/migration70.changed-functions.php

    Minor nitpick stuff on functions that shouldn't make a huge difference, much of this is documented in the functions themselves in the reference so none of these should be deal breakers unless you're doing something really stupid.

    The final bit of incompatibilities is the stuff that just flat out doesn't exist anymore:

    http://php.net/manual/en/migration70.removed-exts-sapis.php

    ereg has been deprecated since PHP 5.1, both mssql and mysql have been deprecated for over a DECADE of them telling us to use mysqli or PDO instead, I don't even know what sybase_ct even did, and really the SAPI's were unreliable rubbish that I never could get to work in the first place, so good riddance!

    IF you've paid ANY attention to what they've been telling us to STOP doing, and STOP using since PHP 5 dropped in 2004, there is NO excuse for existing code to fail by moving to PHP 7. It's only if you've been sleazing along using outdated crap from PHP 4 and/or broken inept methodologies that NEVER should have been used in the first place that it should even be an issue.

    Sadly that describes (pulling a number out of my arse) about 99% of the code in circulation. Much like how most people sleazing out HTML have their heads permanently wedged up 1997's backside, most people sleazing out PHP have their heads permanently wedged up 2003's rump!

    We've been told this shit was coming for A DECADE!!!

    there's a reason when people STILL use mysql_connect I have the overwhelming urge to pour a can of draino down their gullet in the back of a taxi like a pimp who caught one of his ho's holding out on him.
     
    deathshadow, Dec 1, 2015 IP
  13. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #13
    They switched the evaluation order on some things, it has it's own bytecode cache, they've increased reserved word restrictions, and reduced the number of default API's and commands installed in the language.

    Most if not all of the crap that was "deprecated" is now just plain GONE! ... and good riddance.

    PHP is an interpreted language, the more "aliases" to the same function, more function libraries you have, and more commands and constructs you have, the slower it's going to be. Objects because of their scope are actually FASTER in an interpreted language, which is why they can't get rid of the stupid mysqli_ function aliases fast enough for my tastes.
     
    deathshadow, Dec 1, 2015 IP
  14. ketting00

    ketting00 Well-Known Member

    Messages:
    772
    Likes Received:
    27
    Best Answers:
    3
    Trophy Points:
    128
    #14
    Thanks @deathshadow

    Wow! That's just wow!

    Is mysqli_ function really faster than PDO. The real reason I switched to PDO is just in case I switch database types. I don't really see the different from the switch.
     
    ketting00, Dec 2, 2015 IP
  15. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #15
    I've never heard of it being faster -- the only reason it might be is shoving bindparam and bindresult down your throat, but that would depend on what type of query you use. Another reason you might see a speedup is that mysqli has an explicit close method, so people are more likely to use it completely forgetting to do $dbPDO = null; to release the PDO connection.

    Some people out there might be making claims of speed based on faulty assumptions or using broken methodology; one classic example of this is using "prepare for everything" even when not passing data or actually needing the result. Another is that "named placeholders" are slower than unnamed ones since it has to parse them; but it's not like PDO can't do the generic "?" placeholder. (I hate that they use the term placeholder, it's a LABEL in any classic database system)

    But really it's not like PDO doesn't have those equivalents, so it's just a matter of knowing when to use them -- and honestly if those make any sort of real world difference, there's probably something wrong with the code.

    There are SO many advantages to PDO over mysqli -- named "placeholders", parameter passing via PDOStatement->execute, a slew more fetch methods, object mapping, etc, etc ...

    The only reason I could see to even look at mysqli is if you're too stupid to handle the object oriented version -- a lame excuse and the functional wrappers are something I say need to go away --- or if you want to perform multiple queries from one query string. That remains PDO's greatest weakness in that you can't do more than one query per ->prepare(), ->execute() or ->query(), but really both of those should be non-issues if you've thought things out well enough ahead of time.

    Of course, I love that the object version of either can be extended to allow things like "named queries" just like old-school databases did to provide security -- making it much harder to do a script injection when the queries are loaded from JSON or a INI file as private strings in the object. Something else the mouth-breathing halfwit procedural versions can't do.

    Laughably, those stupid procedural wrappers for mysqli are seen as a stepping stone for people who only know mysql_ -- but their mere existence lets people continue to sleaze along with broken methodology which is why I tend not to recommend that one.

    Really though any speed issues should come from the database itself, not from the API. IF there is a measurable difference I would call into question the methodology for the testing, not the API.
     
    deathshadow, Dec 2, 2015 IP
    ketting00 likes this.
  16. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #16
    Oh, and for those of you who want the short version:

    If your program requires more than five minutes of testing to work in PHP 7, you are working from decade old methodologies and have been giving the finger to what they've been telling us for just as long. IT'S BEEN TEN YEARS YOU {string of expletives that would make Marines and truckers blush omitted}!!!

    I am likely putting that to the test in local hosting tomorrow, with real world deployment over the weekend. I do not foresee any headaches as I've not used any of the rubbish they've changed or gotten rid of. The biggest forseeable headache is whether or not ISPConfig 3 works in it as I have that on my VPS for two users who are somewhat less competent than I am and not willing to go hardcore into editing the .conf files (not that I want them to either) -- allegedly it does work just fine so...
     
    Last edited: Dec 2, 2015
    deathshadow, Dec 2, 2015 IP
  17. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #17
    Local tested, only ONE of my sites had an issue, and that was actually code I didn't write that -- you guessed it, used list()

    Laughably it's been tossing errors since I upped to 5.6 and just didn't notice; used to be if you had more list parameters than there were array indexes the extra ones were set to false. They don't do that anymore. I just recoded the whole thing to handle it differently anyhow in like 5 minutes and a third the code. :p

    Now I'm arguing with myself -- on my VPS do I wait until there's a prebuilt .deb on the repositories for installing it, or do I build it myself from the source?

    I might wait, I like Debians policy of "wait until something is proven before putting it in the repositories" as opposed to the "bleeding edge, who cares if it's tested" that's the hallmark of other Linsux distros. (Yes, CentOS, I'm looking at you!)

    I likely will continue testing in 5.6 and 7 locally until I'm 100% converted.
     
    Last edited: Dec 3, 2015
    deathshadow, Dec 3, 2015 IP
  18. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #18
    Well folks, I bit the bullet and built from sources, incorporating it into ISPConfig 3 as an option using the instructions on howToForge:

    https://www.howtoforge.com/tutorial/how-to-install-php-7-on-debian/

    Given I used their instructions for the "perfect debian + ISPConfig server" on my VPS in the first place, things went relatively flawless apart from one of the packages they want you to update/install -- "libjpeg62-turbo-dbg" -- change that to "libjpeg62-dbp" and you're good to go.

    Using that method I can choose 5.6 or 7 from ISPConfig, though you have to restart apache manually for the change to take place. So far these two sites of mine:

    http://www.ewiusb.com
    http://www.deathshadow.com

    Have been switched over and I'm not seeing any major problems with them.

    So.. yeah, by paying attention the past DECADE and actually not doing all the crap we've been told not to do in that time, I had ZERO problems migrating to PHP 7.

    ... and confirmation:
    http://www.cutcodedown.com/phpinfo.php

    (Note, deathshadow.com may go 500 on and off the next few hours as I dick with configuration options.)
     
    Last edited: Dec 3, 2015
    deathshadow, Dec 3, 2015 IP
  19. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #19
    Just an update, 7.0.1 dropped this past thursday (Dec 17) and I've upgraded to that on my production server... It's stable and ready for use.

    It's also DAMNED speedy. I missed a very important detail about it, they've added some "just in time" compilation to it -- and are caching that too. It lives up to the claims of being at least twice the speed of 5.x

    I'm really hoping the speed increase alone will get more people interested. You'll hear claims like "most of the load is in the sql" and while that can be mostly true, given some of the bloated rubbish nonsense people make their PHP code wade through to create the output (or even the bloated nonsense that is that output) it's more of a factor than people think.

    See why things like OPCache, eAccelerator, and APC create DRASTIC performance differences -- hence why OPcache has been included with and enabled by default on PHP since 5.5. Now we have JIT compilation, caching of JIT on top of that? It's delivering spitting distance speed compared to HipHop Virtual Machine, surpassing it in some areas if you tweak the cache settings and just throw RAM at it... without being "one more thing' to have to set up or worrying about it lagging behind version and feature-wise. (since HHVM doesn't have a lot of stuff past 5.4 in it)

    PHP 5.6 was TWICE the speed of 5.2... resulting in that tug-of-war one-upmanship between PHP and Ruby where depending on the bench used they were trading places. This jump means that PHP is now faster than Python and is looking like it may actually kick Java's backside! (Which HHVM already did -- now mainstream is right there too!)

    Hell, with it compiling to an intermediate bytecode and using JIT compilation, with proper caching there's no reason for it not to be Java or .NET's equal now! If they get async IO going like HHVM (and there are guys talking about it in the internals discussions) that would catapult them ahead.

    Though you can already do some things to speed it up in ways most people don't even think of... It seems like pThreads (A PECL extension) is WAY more efficient now, both threads and workers having less "congestion". Nothing like leveraging those extra cores if nothing else is going on... or starting two queries at once on different remote servers and having them execute in parallel... I've actually been playing with processing the output from one query whilst running the next -- stop that pesky "block" on execution that may or may not be necessary. While it "worked" in 5.x, it just... I dunno, feels bettter now. (hoping that's not placebo of "ooh, shiny and new")
     
    deathshadow, Dec 20, 2015 IP
  20. ketting00

    ketting00 Well-Known Member

    Messages:
    772
    Likes Received:
    27
    Best Answers:
    3
    Trophy Points:
    128
    #20
    I hate to hear this. It doesn't support Ubuntu 12.10. My hosting service provider have yet to include it in a quick_install stack.

    I'm not a Ubuntu-savvy guy. If I gonna reinstall Ubuntu, I've to reinstall everything else manually :p
     
    ketting00, Dec 20, 2015 IP