 Well, good afternoon. Hello. Thank you very much for coming to this talk about New Wave PHP. If you are sat all the way in the back, would you mind coming a bit closer? There's lots of seats down the front and it's a bit weird to have people sitting at such a very safe distance. So while I introduce, just please get out of your chairs and come down a little bit and join the rest of the group. My name's Lorna and I come to you from the island we call PHP. I keep saying to people when they say, oh, how do you work with Drupal? I keep saying I haven't actually installed Drupal. It's becoming my catchphrase. I'm definitely going to at least install Drupal before I come to my next Drupal con. But that means that there's no Drupal context in my talks. I'm just here to tell you what's happened in PHP and then I'm going to stand back and watch as you build great things based on that. Before I talk about new PHP, I want to first of all sort of set the scene, describe the landscape of PHP and its story that brings us to here. So the landscape looks something like this. We have PHP 5.2 over on this side released in 2006. Really solid version. 5.2 something was the minimum requirements for Drupal 7. So a bunch of you are running either on a 5.2 platform or just using the 5.2 features because that's the agreed minimum platform. 5.3, 2009. 5.3 was a landmark release in the world of PHP. It has so much good stuff. You're about to see a lot of it. There is so much good stuff. It's only some kind of technicality that I don't understand, which means that PHP 5.3 was not a major version release for PHP. We didn't break a lot of backwards compatibility, but we certainly introduced a good chunk of new features. 5.4, 2012. 5.4 is a really interesting release because you can see that at this point the releases start to get closer together. PHP adopted its RFC process and aspires to an annual release cycle. We actually run at about 14, 15 months between releases at the moment in PHP. I still think that's much better than three years. So it's all good. From 5.4 to 5.5 to 5.6, smaller intervals, this means fewer features. To upgrade between these systems is much, much less of a big deal because the difference between the systems is much reduced. 5.6 is current stable PHP. 5.5 is stable PHP. 5.4 is now in 12 months of security fixes only, which I expect will mean that we roll a single, final 5.4 release in September next year, and that's your lot. Nothing else will get fixed. Then there's this fog of unknown. There is a great unknown in the future of PHP. And at some point, on the other side of the fog, will be PHP 7. I'm not going to talk about PHP 7 today because I think the Drupal community is pragmatic and we deal with real things. So this is where we are right now. This is today and we're on PHP 5.6. The bad news is, Drupal, you are here. 2006. The good news is, that means there's loads of good stuff ahead of you in PHP which already exists, which everyone has already written about, which is ready for you to use. So let me show you the best bits of the new Shiny. The first feature I want to cover seems like such a small thing, but it'll be in every project you use and everyone can understand it. This very familiar dur name underscore underscore file in Cantation, in PHP 5.3 we introduced another of those magic constants. So underscore underscore dur underscore underscore now works in PHP 5.3 onwards to get the directory name of your currently running script. It's the little things that make all the difference. Also in 5.3 we introduced a feature called anonymous functions. I know that most of you are full stack developers, so you've probably seen these in JavaScript. For me from where I'm standing now, it's really difficult to imagine that anonymous functions wasn't always part of PHP. 5.3 has been out for five years, so I guess I just have a really short term memory, but having this ability in your platform opens the door to all kinds of really neat and elegant ways of expressing the functionality that you are building in your applications. So where once we would have had code that looks like this, I'm declaring an array. I'm declaring a function. The function accepts two parameters and I use it for an array walk. This function here that formats my array when called by array walk is a use one's function. I don't want to discover when I come back and need to change my function that some clown has reused my function somewhere else in the application completely because by coincidence he needed to print the same array structure out. And now if I change it where I originally intended it to be used, it's going to have a knock-on effect somewhere else. Anonymous functions are perfect for this single-use functionality. So today the code would look like this. The array is the same when a call array walk, instead of passing the name of the function or another callable thing, I can just declare in the place where it's going to be used, the function that applies here. So it allows us to do very neat one-off pieces of functionality just in the place where they are needed without having to give them names and kind of polluting our namespace. We can also declare these anonymous functions and assign them to variables. We can pass them as arguments. We can take this little piece of functionality and inject it as a dependency to some other code. You might have a class that has an array walk and you can give a different set of functionality each time you call it since some really neat sorting solutions which do something much like this. Namespaces are a game changer. You've probably been hearing quite a lot about them this week. Namespaces really changed the world of PHP. They changed the way that we organise our code. They changed the way that we package our code and the way that we share our code as a community. Drupal 8, building on symphony components, it's namespaces that makes this possible. When you write code, you will put it in a namespace or perhaps some nested namespaces that relate to what that code does. The problem with combining frameworks, CMSs and other libraries is that everybody's got a log class and a user class. We can't declare two of those in PHP and the world ends. Prior to 5.3, we sort of prefixed with lots of long-winded class names on the beginning. CEN framework was particularly bad at this. Now we have namespaces. We can combine those two things. We can give our classes short and snappy names. They have a full name. We can give them a nickname to keep our code very readable and yet still be specific about which log class it was that we wanted to use. Drupal has adopted the PSR4 standard, so PSR, PHP standards recommendations. We agree on how to do stuff and that allows us to interoperate between different frameworks and different applications. PSR4 specifically is about autoloading. It lays out the rules for how to name your code, your classes, your namespaces, how that should map to where the files are and which directory they should go in and how everything should be named. When you follow these rules, now I can load your code just as easily as his code and it opens up the possibility of tools like Composer that can be literate to understand the changes that we make and the way that we want to collaborate and use the tools built by one person to build upon them, stand on their shoulders and build the next thing. Namespaces open the door to Composer. This is a big change in the PHP community. We are no longer... Are you a Zend developer? Are you a Symphony developer? Are you a Cake developer? Those lines are blurring. I was at a conference in 2009. PHP 5.3 was probably just released or nearly released. A bunch of framework leads sat down in the same room as one another and agreed how they would implement namespaces in their own projects so that everybody else could start to cross, pick and mix all the different modules. At the time, that was unheard of. The frameworks were at war. They had contempt for one another. The rest of us stood in the corridor listening at the door to make sure everyone was okay. Out of that meeting came the PSR standards. Now we have Composer. We can build on that. Namespaces open the door for this. The actual implementation of namespaces is trivial. At the top of your class file declare which namespace you want this class to be in. You will have many classes in each namespace and they will probably map when namespaces match directory names and the class names are within that. I've declared a nonsense class. It has one property and one method. I love writing example code for slides. It must be no more than 11 lines long. 58 characters wide. Go. When you call this I've required the file. I've included the file there and I can just use that namespace to say the nonsense class I mean lawners nonsense. Then I just instantiate the class call the method. When you're using namespaces if you do want to use a class name that's in the global namespace like standard class you just need to prefix with the namespace operator so PHP knows go back to the top of the tree for this. I totally forgot to mention this at the start but if you want to ask any questions just come down to one of the mics and then I'll immediately just call on you. So you can wave if you like but I need you to come to the mic to ask a question come anytime. Let me show you a feature from PHP 5.4. I know that you're moving to 5.4 for Drupal 8 with a minimum version. This is good news. There's good stuff here. PHP's own web server. Okay. So PHP needs a web server. This is the feature that made me go really I've been setting up virtual hosts for 10 years and they work really well and let me know you are solving a problem that does not exist. Then I actually started using PHP's own web server and I now cannot imagine life without it at all. So it just turns out that I know nothing and this is a really cool feature. It's part of the command line PHP setup. So you run PHP with this dash capital S localhost port number. Now if you visit localhost colon 8080 in your browser the files that were in this directory become your web route. You don't set up a virtual host. You don't need to reconfigure things. If you're using Subversion and you have multiple branches checked out to different directories you don't need to reconfigure your routing you just spin up the web server in the directory that you're interested in and you work with it from there. I'm a consultant. I work with lots and lots of different projects and I also write books and talks and example code for all kinds of things. There's hardly any entries in my virtual hosts directory now. Everything's just spin up the web server and have a play. When you do this is a screenshot of what happens. So I've started the web server from the command prompt and it kind of says yes hello I'm working. Then it starts to show you the web logs so you can see your access logs as they go past. If an error occurs you'll see that here as well and I find it a really convenient way to develop just to fire this up have it running in my terminal and see oh wait there's a lot of red there I think I broke something. It's very very instant I see a lot of red generally I break stuff. It's very instant and it's very real I find it really easy to work with. Some things you need to know about the web server. It's written in PHP so if your PHP fatal errors you just lost your web server. One crashes the other one just went. It's also not at all intended for production use. It serves requests sequentially. Think about that. Whenever anyone hits your site that request has to complete before the next request can begin to be served. You're not going to run this in production. Someone always comes and tells me that they do. It's awesome for things like admin tools running internal services in the office web server for the bug tracker anything which isn't going to be high traffic it's perfect. But for a client facing site probably not. There's a load of things you can do with the web server so let me just give you a quick run down. You can instead of local host specify a domain name as long as that's in your host's file it'll work. If it's in someone else's host file and the IP points to your machine and they're on the same network and they can access it too. So it's a very easy way to put up a test site in the office. The dash T is to specify where the web root is. I mentioned it's quite easy to crash this web server especially if you're using slightly flaky PHP projects. That'll be me. So you'll probably run it under a tool such as supervisor D where if it crashes supervisor will say oops and bring it back up again. You don't typically run that from the directory where index.php lives so dash T just lets you say this is the web root. Run it from here. The dash C is to supply a configuration file. PHP ships with recommended INI configs for development and production. I would recommend that when you when you use PHPs built in web server that you do use a config file. By default it doesn't use a default config file or anything. It just uses PHPs built in language defaults and they're a bit odd. Some of them have just been there for a long time and the memory limit is really low and strange things happen. So I would recommend that you use some kind of default config file as any PHP.ini is better than what PHP itself has as defaults. The very last thing here is routing.php and that handles things like rewrites. So if you are using pretty URLs, you're using Apache's mod rewrite or one of the equivalents you can do that by re-expressing those rules in PHP and then adding that kind of prepend, if you like, file to the command line when you run the web server. So you can still have your pretty URLs. Very, very nice. Like I say, this is the feature that made me go well really, do we need a web server? Is there a problem? I now love it. I use it all the time. Give it a go. Oh, speaking of features that we... I never knew we needed. Short array notation. I teach PHP to beginners. Believe me, we have enough ways of expressing array notation already. That said, again, this is a feature which has grown on me and which I use myself now. 5.4 enables you to know that it's always going to be there. So these three blocks of code on the screen behind me are equivalent. The first one, just keyword array, round bracket, give key and value pairs. The second block declaring each index on its own line. And finally, the new short array syntax that comes in with PHP 5.4. It's not JSON. It's still got PHP's array arrow notation. So what's the name of that operator? Anyway, it has those array pointy bracket things in it. But all you do is replace this array with round bracket, closing round bracket, with a pair of square brackets. So it does make things quite tidy, quite easy to read. I think you might well see this in your code base, so I wanted to mention it. Another thing that I think you might see is the array dereferencing. This is a feature where when you call a function and it returns you an array, you can just immediately say, I only wanted this element. You can immediately refer to the key. You don't have to assign the result of the function call and then access the array element that you actually wanted. So in this example I have a function that returns a list of dwarves as many as will fit with this many characters. When I call getList, it returns before elements, but I only want the first one. And so I can call the function after the round brackets immediately append the square brackets to access the array element. So you can dereference the array all in one line. I would contend that if you have a function that returns what you actually wanted from it, then you might have a problem with your function. However, this is a pretty common use case for situations where you're getting, maybe you're searching for something, but you're searching by ID. So you're going to get a collection of results, but you know that you only want one. You can just very quickly dereference it. Again, it's a 5.4 feature, but you're all moving to 5.4 imminently soon, hopefully. You'll see this, and you'll be able to use it in your own code as well. This echo shortcut, I think, is a bit of a gotcha. So let me mention it. I'm not sure if you're going to see this in Drupal 8 or not. Perhaps someone can tell me. PHP 5.4 actually removed all kinds of ridiculous things from the language. But it also removed the short open tag config setting. Yes, you see. So you guys have seen the light because Drupal projects never use the short open tag, and therefore stuff basically will work wherever you put it, which is perfect, awesome, well done. However, the rest of the world did use the short open tag, and we've been discouraging it for years and years and years. However, most projects in the PHP mainstream world don't use the classic short open tag in place of opening PHP tag, but they do use this echo shortcut. As of 5.4, the short open tag is not available ever, and you can't turn it on. And the echo shortcut is always available. You can't turn it off. So this pointy bracket, the second option above me, pointy bracket question mark equals sign is equivalent to an opening PHP tag and the echo keyword. So those two code samples on the screen now are completely equivalent. We often use the echo shortcut in PHP projects if we're not using a templating language, to just put placeholders into HTML. So you have good front-end layout, everything is good. Where you need to drop in the dynamic placeholders, you will commonly see this echo shortcut. I don't know if you'll start to use it in Drupal with Drupal 8, but if you want to, it's here, and it doesn't mean enabling the short open tags, which you're quite correct, was always a bad thing. PHP 5.4 brought in a feature called session upload progress. You know when you ask a user to upload a file, and maybe it's quite a big file, and maybe they're on fairly slow connection, they just don't know if they're nearly there or not, and you can do some kind of flash to track it, but it doesn't work for everybody. PHP 5.4 introduced a feature called session upload progress, which allows you to get some, as the upload is taking place, PHP tracks how the upload is doing and writes an update into the user's session repeatedly. So you can keep serving information as like a regular poll update, showing them how their upload is going. So hopefully, if you are dealing with a site which allows users to upload media or documents, they can be quite large. This lets you let them know they're nearly there, please don't give up now. Or you are never going to get this file uploaded over this connection, you should quit now. So the session upload progress is pretty cute, and I've seen some nice implementations with the HTML5 progress bars as well. It looks like this. So you have your form you know how to write forms, all of you know how to write better forms than I do, and then you have a hidden field on the form, which uses a predetermined configure session upload progress field name, and you give it a value. So you just need to give the upload a unique value so that it's a bit like a CSRF token, right? Just a value that we can then link it back to later. So you put this hidden field on your form, and the user chooses which file to upload, they submit the form, and in their session, you get this upload underscore progress underscore whatever the identifier is, and all this information about how long it's been going, and how big it is, and how far we've got through, whether we've finished or not yet, and so on. So you can then have some kind of probably Ajax-y feedback to your user that shows them how far they are through this upload process. It's really important. It's something which we haven't really shattered about in the PHP community, but I think for Drupal people, you make websites, you give good feedback to users. This is a key feature. I think you'll see it showing up, and I think it will be really, really valuable. I mentioned about the short open tag. I once gave a talk about PHP 5.4, where I said, we've removed the nonsense, and somebody said all of it. No, good point. Not all of it. But in PHP 5.4, we did remove a bunch of things that made absolutely no sense. This is part of a wider story in PHP. PHP 5.3 shipped with a new error reporting level. On 5.3, or later platforms, you can enable an error reporting level called PHP 5.3, and that will put an entry in your logs for everything you do which isn't going to be available on the next version. So, we launched PHP 5.3, which I accused of being in a dim and distant past. Really not that long ago. And with PHP 5.3, we introduced the eDeprecated flag. So at the moment that 5.3.0 was released, we had already specified what would be removed in 5.4. So, this marks the sea change for PHP. Stuff will not just vanish if you happen to upgrade PHP or run on a slightly newer install. Stuff will not just go away on you. We have eDeprecated. So, 5.3.0 has eDeprecated in a list of stuff that's going to be gone in PHP 5.4. So, when we got to 5.4, awesome. Now we can take away all the stuff that was known for ages that we shouldn't have. We didn't have a way of safely removing it without breaking your installs. So, things that are gone in PHP 5.4, register globals! Hey! Finally, I know it's been off by default for something like 15 years. Really, let's not use it. So, that is gone. You cannot turn it on. Your PHP 3 code is finally is dead. Register long arrays is gone at safe mode is gone because it's not safe, and magic quotes are gone because they're not magic. We've disabled allow call time passed by reference completely. This is something which you could turn it back on. It's never been good practice and I very much doubt if it will affect you guys. But it is gone, so I did want you to mention. I did want to mention that to you. I'm so sorry. We've removed the Y2K compliance flag. So, if anyone is concerned about the Millennium bug, we no longer support that. Why it took us till 2012? I don't know, but there we are. Because we didn't have a safe way of taking it out, right? We removed the e-redge functions. This is something that might hit you depending what's going on down in your modules if the e-redge functions have been used somewhere. There's another set of regular expression functions in PHP called the p-redge functions. We just standardize on those. So, if you have e-redge stuff buried somewhere in your application, you just need to revisit that and replace it with a p-redge for 5.4 or later. That is a little bit of a gotcha if you do have that code in, but it shouldn't be horrible to replace. Shouldn't be horrible. Hopefully. OK, here is a 5.5 feature, but bear with me because it is relevant to you, even on earlier versions. Again, I'm not sure why it took us this long to realize that every PHP website in the world has a login. We probably need to agree on a good way to store passwords. Here's a clue. MD5ing the password is not a good way to store it. So, with 5.5 shipped new password hashing features the user registers for your site and they set their password a secret password. I shouldn't use my own passwords in examples. Must take that out. To store this password, you use the password hash function and you say please hash this password. It takes a second argument which is how you'd like to hash it. Currently the recommended method is bcrypt. The password default flag will always hash it in the good way. So, if in two releases time there's a better good way to do this, the password default will start using the new way instead. So, you put this in here, you forget about it. If you look at what happens, you get this garbledy nonsense which has kind of dropped off the screen. So, you need to make your password columns wider. I just made that mistake this week. Stored in this string is the algorithm that was used to hash this password, the salt that was used to hash this password and the hash of the password. What this means is in contrast to a table of just md5 passwords where you can very easily look up the values, even if every single user on your system has a password of QWERTY, anybody who manages to get your password database still has to look at each individually hashed password, look at the algorithm, look at the salt and then generate a table of all the likely values and look up if you're in it. So, it makes the cost-benefit return on stealing password databases and trying to crack them much, much, much much lower. It's built into PHP, there are no excuses. Because some of the information about the password is stored in the password hash, the way that we check if we've got the right one is a little bit different. So, to check if it's back what we need to do is we need to take the value that we stored in the database which is the existing hash variable here and whatever the user is trying to log in as, which is the secret password and we call a function called password verify. So, you can't rehash the new password and compare them because you need some information from the previous hash to make the right forward hash. I feel like I'm making sense. So, you do password verify whatever they just try to log in with and then hash your aiming for to check if they're equivalent. If you are not on PHP 5.5 yet that's fine. We implemented this in user land for you. We also implemented this in in Anthony who also fitted this feature to CORE. So, for PHP less than 5.5 go here, install this library put it at the top of index.php with a comment that says to do when you install PHP 5.5 remove this include line because you'll be declaring it twice because it's in the language. So, just include this, use it and if you upgrade this application later take the require line out and it'll all just work. So, if you want to make the right forward hash it's fine because Bcrypt was broken before that. There is a minimum version but please, please, please look into this and certainly for all your new sites hash passwords this way. If there's one true way it's this way. Op caches. Let's talk about op caches. The days of making websites especially relevant for Drupal, building some really big and impressive sites these days. In versions of PHP 5.3 and earlier you will install APC. You know this. You set up a server, you install APC. All is good. We had a problem with APC in PHP 5.4. I can't tell you any more about that because I don't understand, it just doesn't work. But sometimes it doesn't. So, no APC. I think this really affected the adoption rates of PHP 5.4. The adoption rates of PHP 5.4 are actually still pretty low. 5.5 is growing much faster and I expect everybody to go direct to 5.5 now. So that was related to the APC. From PHP 5.5 onwards no APC. However, APC does exactly the same thing to as far as I understand it and is built into the language. So this is what used to be Zen's cache extension. They open sourced it and put it into core. For 5.4 you can install APC from Pekal. For 5.5 it's in the language except for one tiny detail it's disabled. So we fitted the opcode cache as standard but it's not turned on. So just set these opcache enable and opcache enable CLI settings when you upgrade to PHP 5.5 and then you've got an opcache entirely enabled. I've run through a bunch of features there. Does anyone want to ask me any questions before I move on to the next section? Making life nice and easy for me today. Okay. Let's talk about your existing systems. You're all running existing systems. I assume they're not all on 5.6. Let's talk about upgrading an existing system. This might seem like a weird and scary idea. But now look at the performance graphs. And 5.0 and 5.1 and things are like I would have to rescale the whole graph. They're slow. This is 5.2, 5.3, 5.4, 5.5, 5.6 running a benchmark. So what I'm graffing here is how long it takes PHP to run exactly equivalent code on different versions of PHP. It's totally unscientific because I did it on my laptop but you get the idea. I think the relative numbers are true and this is repeatable. I see this pattern every time I run the benchmarks. If you're currently on PHP 5.2 and you were to upgrade your platform with no code changes to let's say 5.4, 5.5, you would have something, you would see a massive increase in performance. I heard a really good story from my good friends at ICOS. They saw me give an early version of this talk a few months ago. And they upgraded one of their sites from a 5.3 platform to a 5.5 platform and sent me very excited tweets saying it's 50% faster. That's a lot. It's a lot less hardware for either you or your clients to pay for and it's for free. You don't pay for the upgrade. You pay the time and the mental stress of worrying what's going to happen when you go live. You're not paying for the upgrade. You're not paying for improving the performance. It just runs faster. It's kind of why I like free software. It sort of upgrades itself when you're not looking. That said, the upgrade process does not always run smooth and I want to make some recommendations for how this could look. There are lots of reasons to upgrade but how do you actually do it? First of all, turn on e-deprecated on your current platform. If you're still on 5.2 you have the hardest job of all. There's no e-deprecated and there's some big changes in PHP ahead of you. Coming on to 5.3 if you're not there already that's the last of the tricky migrations in PHP. It's not quite 5.4 to 5.5 because there's not as many backwards compatibility breaks but 5.2 to 5.3 I'm still in favour of doing it but please don't think that I just said you should run your code on 5.3, it's going to be fine. If you're still on 5.2 you're not in a great position. If you can get to 5.3 turn on e-deprecated turn on e-deprecated on a live server watch the logs. Give you a really good idea of what is there which might cause you a problem in a future version. Compile the version of PHP you want to go to and run whatever tests you have. If you have a simple test if you have a PHP unit if you just want to spin up with the web server and then go through whatever use the testing you would normally do do that. You don't need to completely change your system and install a whole new version of PHP you can just compile one or if you're using like a lamp lamp lamp those things you can usually click to change the versions in it. You can tell this is an area I have lots of experience with. Click there's a thing. You people who have things to click on you can probably click on a thing. When you think you're ready try upgrading a staging platform or one of your testing platforms. Go through your full rigorous we're doing a major release type testing and see what happens. You may be surprised at this point how few pieces of the sky have broken and fallen on your head. I have had good experiences of doing upgrades and it's something that I do a bunch of migration. I have seen some good upgrades and somewhere you upgrade a server a lot of errors come out but it's mostly the same problem in lots of places. So it boils down to actually only being four or five big problems and some little problems. So I think it is possible to upgrade. There are lots of reasons why you might want to. I mentioned the performance one already and if it was always simple that would be a no-brainer you'd all be running 5.5. You may want to upgrade over the next 12 to 18 months to avoid needing multiple hosting platforms as your new projects moved to Drupal 8. Yes, you'll need a 5.4 minimum platform but there's no reason why what you have already if you're running a VPS, whatever there's no reason why what you have already shouldn't share that new platform. So you'll need to shell out for extra hosting and I think especially for the small businesses that do so well on Drupal that's quite an important point to make. The new hosting doesn't need to be as well as what you have. Finding hosts that are any good that's a really hard problem. PHP I don't really know why it's so acceptable to run really, really out of date versions of PHP on hosting. It's just like a lot of the hosts don't know very much about PHP. So how can you pick a really good host? Well you can ask around and see what people will recommend. I have done this for you so the next slide is a list of possible hosts that I got from asking Twitter very scientific. New projects today shipping onto new platforms so if you are commissioning a platform for a new project or if you're buying new hosting for any other reason those platforms should be 5.5 or later. There is no reason to ship on an earlier platform right now. 5.5 or later. 5.4 major security fixes only. All kinds of things could be wrong with 5.4 if we find it now, no one cares. 5.5 minimum version. The hosts are out there and want us to vote with our feet. PHP has some wonderful new features not to mention the excellent performance improvements why shouldn't you have those as standard? Why shouldn't everybody have those as standard? Why shouldn't the Drupal hobbyists just trying things out in their spare time at the weekend that's a common background for lots of us? Why shouldn't they be seeing PHP 5.5 as standard when they buy shared hosting? We have to educate the hosts and we do that with our wallets and we choose hosts that understand what a current version of PHP is. So some questions I would like you to ask your hosts what versions of PHP are available? The correct answers here are 5.5 or 5.6 If you currently have 5.4 and there is a 5.5 option available if you ask nicely fine, good enough Anyone who tells you 5.3 is standard doesn't get your business This is not going to support your organisation moving forward whether you are one person doing this as a hobby or a big agency making really excellent big complicated projects Our backups included This isn't really related to versions of PHP it's just a really good quality measure of hosts hosts that care will if not require that you take their backup service at least offer it so that you have some confidence that you could get everything back really quickly if needs be This question which extensions are available and which extensions can I install? If the answers are none and none then again maybe these are not PHP specialists Even if you don't need extensions supporting them gives shows the organisation has a good understanding of PHP There are lots of things which I like to install in extensions on my platforms for example xhproff is a performance tool that I use to it's safe to use on a live system it just measures a small percentage of all the traffic gives you great overall information it's a pecle extension you need to be able to install extensions to use those kinds of tools and I think we'll see more of them I'm seeing templating languages which are written both in PHP or the option to have them run faster because you're running them as a C extension You need to ask this question when you buy hosting Can I get support with my PHP setup? Had a great meeting with a very local hosting company with me and we're both suppliers to the same client and the client said what help can we get with our PHP application and the guy said we can certainly help you with that I'm thinking I drink with these people they're ruby people not sure how you're going to support my PHP actually they've been fabulous and really really helpful we haven't had any particular PHP problems but ask this question can I get support my PHP setup if you're in a position to look at my config settings and advise me or am I completely on my own there's a lot of competition in the hosting market and I'm quite interested to see how we find the good ones and is not related on price at all the best ones are not the most expensive so here is what Twitter gave me I am sure there are people missing from this list that absolutely deserve to be here so please tweet them at me I am at Lorna Jane and I will just keep adding slides to this deck and re-uploading and then you can look up a crowd sourced better list from my Twitter account my Twitter followers requiring 5.5 minimum this is what I got Server Grove Server Grove I know Pablo personally he is an absolutely very geeky person and he's symphony nut so he can help you with all of your Drupal stuff as well Linode are great 5.5 available I host with Linode Digital Ocean got recommended Site Ground Rackspace Rackspace are here so this is a very unofficial list if you would like to add anything to it that would be awesome and I'll just make a bigger unofficial list and either put it in my slide deck or maybe blog it for you or something they are out there they are affordable they are real they are running 5.5 as standard they understand your needs and they can support you there is no need to settle for second class hosting for your first class applications because I am sure they are all fantastic this slide says Drupal 8 and the future Drupal 8 is the future not just your future but the future of all of your future clients and the future of people who haven't even installed Drupal don't know yet the future for many people coming over from PHP as you become a bit more programmer oriented perhaps in your back end and particularly as Drupal 8 is developed PHP has evolved hugely I know it's a pain to have the minimum version increase to run the newest version of Drupal I know, I know, I know you have service that is set up and run perfectly well no one is going to pay you to install a new platform I understand but really good things have happened in PHP your minimum version increase gives you a load of fabulous new tools for the people building Drupal as well as for the people using Drupal the increased frequency of PHP releases means that especially if you can get to 5.4 or 5.5 your upgrade paths will not be painful I had a server which launched on 5.4 because there wasn't a 5.5 package available for the distro at the time about 18 months ago and when the package became available because it's in Ubuntu LTS my sys admins were super keen for me to upgrade and they were like when should we do it, when should we take the site out and I was like well I'm actually out of the office but you just upgrade it any time 5.4, 5.5, whatever it'll work, it did that's how the upgrades are and that's how they should be and that's where we are when will PHP get easier to upgrade it did, we're there the future is here your future is based upon it I'm kind of excited I think maybe you're not yet I'm quite excited, there's some new features here I hope that you'll like them and come here, come to the future good features, good performance very software supported security fixes loads of good stuff and Drupal 8 as it gets beyond beta hopefully at a great rapid pace and you'll all be using it in no time at all that's what I'm hoping that's my utopian vision for the future better features, great tools and I'm thinking of composer and all of the kind of using different pick and mix libraries you've rushed wrapping composer so you have this already the improved performance and the stuff that we can build on features like this right, who has questions for me please come to the microphone if you would like to ask me anything at all while you are all rushing out of your chairs to do that then I just wanted to mention this intermediate PHP video if you got the email this morning saying oh O'Reilly are offering you a free e-book click on the link because as well as the free e-books they're giving away my free videos one of them is intermediate PHP so it covers new features in PHP object-oriented programming composer the command line stuff the web service stuff it's really just intended as a kind of people who are competent at PHP and want to be more awesome it's in the video so they've given you a free e-book but it's not even an e-book it's a video so that's a shameless plug for that nobody got out of the chairs so I'm going to get to my cup of coffee even sooner than I thought if you want to get in touch tweet at me, I'm Lorna Jane tweet at me, I'm around until about this time tomorrow and thank you, thank you so much for coming please rate the session and enjoy PHP