 All of our work is PHP, MySQL, and most commonly WordPress. So in early 2013, I found myself living with my dad on the Fraser Coast looking for work. I'd heard that the owner of a local web development company was possibly looking for extra hands, so I reached out to him by email, and this was his response. Now before reading his reply, I had never heard of WordPress. Google told me that it was an open source web framework written in PHP for developing blogs, websites, and applications. My previous experience at this point was with .NET, a little bit of Java from university, and I'd never touched PHP. So I was interested in open source, so I responded to him saying I essentially knew nothing, but I was keen to learn. So I've now been working with WordPress at the same business for the past five years, and in accordance with WordPress standards, I feel duly obligated to give something back to the community. So I wanted to talk today about some of my experiences using WordPress for its latter purpose application development. This is something that I feel isn't really talked about much in the community. So I figured I'd come here today and share some of our experiences, the problems we've encountered, and how we've solved them, and everything I want to talk about is going to be, from my perspective, as a predominantly client facing backend programmer. So I've been using WordPress to build applications. What are applications? A lot of the sites that run on WordPress are content-driven, things like blogs, small company sites, websites with some dynamic content that people come to consume. These content-driven sites in WordPress tend to have custom functionality around them, implemented either within the theme directly or within a plug-in or a number of plug-ins. So an application, by contrast, for this talk is something where the CMS functionality of WordPress is either not used at all or is just a small part of the site. The site is more driven by functionality rather than content, and it exists to complete a specific task in a specific way. So for example, a seafood business might need a way to manage their crazy Christmas sales period. So perhaps they want a website where customers can sign up, place an order ahead of Christmas detailing what they want, and when they want to pick it up, and pay a deposit. This information might then be fed to the packers in the warehouse to pack each order on the day and send out an automated text message to customers when their order is ready to be picked up. When it's all over, the owners might want to pull a report to see sales data and compare this to last year. So with that in mind, you hopefully know that there are heaps of other PHP frameworks available. So from Code Igniter and Laravel and Slim, plenty more, so why would you pick WordPress? And also, why would you stick with WordPress for five years? Well, to be honest, this wasn't up to me. But that being said, we had our reasons. So even though some of our clients were actually pretty big, successful companies operating here in Sydney, all of them wanted simple, cost-effective solutions that could be extended over time if they were successful. And more often than not, the staff that had to use these applications were non-technical. I'm guessing if you're attending WordCamp, you probably know what you like about WordPress. But some of the key reasons we told our clients it was that it was popular, it was known, it was trusted. It had a good user-friendly admin interface. And a lot of our clients already had sites running with WordPress. So it provided nice consistency to either extend their existing sites or to build new applications in WordPress. Finally, it gave them almost full control over their site and its content once it was live. Now for us developers, we liked WordPress because it was free, it was flexible, and it's forgiving. It's easy enough to pick up and you aren't really punished if you don't get things perfect. WordPress provides a lot of the basic building blocks you need to save you from the tedious foundation of work. It can help with theming, routing, adding admin pages, data management, and more. It lets you focus on the bespoke aspects of building out the functionality. And you can also leverage existing plug-ins and themes to speed up development. It's also open source. It has a large community. It's actively supported and it's constantly improving. It has fairly decent documentation and there are heaps of tutorials and blogs and stack overflow questions out there to help you if you're in a bind. So despite what people might think, I believe the past five years has shown us that WordPress is definitely capable of competing in the application space. However, it's not all positive. WordPress is far from the perfect application framework and a big problem with it is actually its flexibility, especially if things get more complex. So like PHP, WordPress will let you get away with things that it probably shouldn't. It's over-forgiving nature is great because it allows developers to execute their vision however they like. And this flexibility of WordPress really is one of its strong points. A lot of the people who use it aren't developers. They're probably closer to self-taught enthusiasts. In fact, one of the first word camps I was lucky to attend, which is in San Francisco a few years back, I was sitting in the audience waiting for the next presentation and there was an employee from automatic sitting next to me. And we started talking and he asked me what my favorite thing about WordPress was. So I told him that I liked that it could allow you to build sort of fast and flexible bespoke web applications to solve real world problems for both small and large businesses. And then he then replied saying he liked it because it was a great platform for people to just easily pick it up and create a simple blog or a website without much fuss. So the WordPress community is fairly large and diverse. This flexibility is clearly a strength, but it also means you come across some pretty horrific things. On top of that, not knowing the ins and outs of WordPress can really bite you. We had a situation a couple of years back where we had to migrate data from an existing website over through to a new platform powered by WordPress. And we found that some of the posts were coming through with incomplete content. So after frantically reviewing my migration code numerous times and stepping through the processes over and over again with no luck, I eventually discovered that for security reasons WordPress wouldn't allow specific content in a post unless you were logged in as an authorized user when creating it. Now this makes sense, but it certainly wasn't common knowledge to me or amongst my peers at the time. And my attempt to test this actually failed because when I did so, I was logged in with my administrator account, but the process that ran to do this was automated and did so without any user privileges set, hence the missing content. So over time, there are a lot of little traps like this that you might find yourself caught in. And we've been caught plenty of times. It's probably best I don't mention the more publicly here, but safe to say there's a bit of a special expression in our company that's often given in response to the question, well, how did that happen? And the answer is because WordPress. So when working with WordPress, the correct approach isn't always obvious, even for simple things. It's both a mix of procedural and object-oriented code. It uses these hooks and filters all over the place and it has a pretty unique structure compared to most other frameworks. The first real question I asked my new boss when first starting out was, where exactly do I put my code? And even he wasn't sure. So there are two places you might consider, and within the theme or within a plugin. So really top level, your themes normally contain all of your views and your visual assets, your front-end logic. Plugins are normally self-contained and attempt to provide a specific feature or some kind of functionality. And the idea is you can switch them on and off at will ideally without breaking the site. But what if you're building an application? So my first project was to create an online hub for finding garden tours around the world, a site where people could view and search for these tours, save them to their favorites and even book for them. It involved a number of custom post types and taxonomies, user accounts with some metadata attached to them, and then a few custom pages to handle the specific functionality. So coming from uni, I believed that logic and visuals should remain separate. So it didn't make sense for me to have any application logic sitting inside the theme. But then on the other end of the spectrum, it didn't make sense to have any visual assets living inside a plugin. So theme or plugin, either option only felt about half right. And if I used them both, I kind of felt like I was splitting the code base. So at the end of the day, the client wants you to deliver a solution that works and they have no need for the perfectly designed solution that you spend forever working on and then never actually deliver. So for this first project, I decided to go with both a mixture of theme and plugin. I've got a rough outline of what you can't even see it there, which is wonderful, but that's the picture on the left. So I created a plugin to hold my application logic and it tackled things like registering custom post types, handling form, submission and manipulating data. I also added in a few classes to help simplify recurring actions. I then built a custom theme to hold all the templates and visual assets, which is the purple box down the bottom, which you can't see. There were also a bunch of other plugins we used just to help speed things up. So in this project, we used advanced custom fields just to help manage the post meta and then to provide a better user experience, we used theme my login. So what about as things got more complex? Well, over the next year or so, we experimented with our larger projects. So the first major project we had, we had to build a fairly large internal system to help manage a nationwide TV infrastructure change. So it involved a series of separate features and we had multiple developers working from different time zones. So for this approach, we actually decided to try creating separate plugins with each handling some kind of major self-contained feature. And then as part of this, we also had a cool plugin set up to handle common functionality. That would be the image on the middle, which you can sort of read. Those plugins there are just written in green and you can just see how each one sort of handles some kind of major component of the site. So the next major project following on from this, we had to do an overhaul of an existing subscription-based membership system where we had to redo the entirety of the membership system but leave the front end intact. So for this time around, we kept that multiple plugin approach, but this time we opted to use MU plugins instead. So if you don't know an MU plugin, MU stands for must use. These are essentially plugins that you don't get to switch on and off. They are always running. As part of this, we also introduced a consistent directory structure across each plugin. And then finally, that Christmas seafood example I gave earlier, for this application, we just had a single MU plugin that stored all of the application logic and then had all of our front end templating and everything sitting inside a custom thing. So throughout all this, what did we learn? Well, without a consistent directory structure, every developer ends up having their own way of doing things. Finding and reading code, especially in a hurry, was very painful and debugging hooks and filters could be an absolute nightmare, especially when things weren't grouped in a consistent or logical way. And everyone had their idea as to what consistent or logical meant. We also found that separate plugins for separate features for one application was a really bad way of breaking things down because over time, all of the lines between these features began to blur and everything just kind of mixed together. We also found that we were duplicating a lot of common code across every project and this felt kind of wasteful. And at one point we actually had to rename our directories and our files to be in like an alphabetically significant order because they weren't being loaded in the correct order and PHP couldn't reference the right functions and methods and all that sort of stuff. But it wasn't all bad. So with each iteration, we learned from our mistakes and we started to get a feel for what we liked. We also started accumulating some useful assets, both code that we'd written and plugins that we liked working with and trusted. It's also worth pointing out that with all of these mistakes in mind, all of these projects were still delivered successfully. They were on time. They met the client's needs and their requirements. So after all of this, we knew that we wanted to focus on consistency and reusability. We didn't want to redefine everything over and over again with each new project and we wanted to introduce some kind of process that we could refine over time. So we came up with something that we called the system plugin inspired by code igniter. So it was essentially a collection of reusable and extendable assets that helped automate all of the common and tedious elements of application development in WordPress. It was essentially our own little framework for building apps inside of it. So for reusability, we kept it in a separate repository in Git, our version control software and had it set up as a sub module for each project. It would then be installed as an MU plugin in WordPress and we would build out the application logic in a separate MU plugin that would leverage those assets. And then finally, we typically create a theme, a custom theme to hold all of our templates in our front end stuff. So you can sort of see the breakdown there and yeah. So transitioning to this process allowed us to enforce a consistent file structure across all of our applications. It encouraged the adoption of programming standards and patterns that we liked such as object oriented or be followed a fairly rough MVC kind of style. And it also saved us from duplicating all of our common code as all of that was now moved to one repository. So it was pretty good. Making things became much faster and finding things was also much faster. And with each project we could make small improvements to the system plugin, feed that back, and so things were a little bit easier next time. But the application space itself still allowed for some flexibility and developers still had the bitties to do things their own way. Additionally as part of this we created some templating assets that allowed us to easily place templates either in the theme, within the application space or within the system plugin itself, depending. So if you were building out a front end page you'd put the assets for that in the theme. If you were perhaps building a custom WP admin page you could put the assets in the application. And then if you wanted any kind of generic full back templates or example templates you could put them in the system plugin. So as always there were problems. So one of the big problems that we knew was gonna happen but it still ended up biting us and early on was that making changes to this common infrastructure within the system plugin itself was costly. The best example of this was that due to time constraints we weren't able to use Composer when we built the first version of the system plugin. And by the time we had the space to come back and add it in we'd found that we'd used the system plugin in so many applications that refactoring all of those existing applications to now handle the new infrastructure was just too expensive and we couldn't do it. We had to give it up. So moving forward we had to very carefully consider both backwards compatibility and sideways compatibility. And eventually there was divergence and multiple versions of the system plugin came to play. And I feel like one of the main reasons for this was that different developers had their own visions as to what the system plugin should do. So on the one hand there's this idea that it should be as feature-rich as possible where all you do in the application is define an array and some configuration values and the entire application is built out automatically. And then in contrast to that there's the idea that it should be as light and as lean as possible where you can place it on any existing site and not suffer any performance penalties. So a good example of this was we had one application that took about six to eight months to build and throughout this time we're making incremental changes to the system plugin. When everything was finished and we had to merge these changes back we actually found that we'd made so many changes it was no longer compatible with the previous version. So we had to fork an application-specific version which was very disappointing. As part of this it also became really easy to lose sight of how to do things in the standard WordPress way. So even though we extended and wrapped around WordPress we tried to keep our stuff as WordPress-y as possible all of our accumulated convenience functions and classes and assets made transitioning back to WordPress kind of painful and frustrating and I found myself getting caught in a lot of the traps I get caught in when I first started out. Like was on the inverse end if we had any contractors who had to come and work on our applications they did find it difficult working within this space as it wasn't quite the WordPress environment they were familiar with. But I do want to quickly point out here that when we came up with this we weren't a bunch of software engineers working on our thesis. We were just three people in our early 20s with three different skill sets trying to solve a real-world problem with a real-world solution. So I spent some time talking about structure but I kind of also want to talk about the database as well. So coming to WordPress I was used to fully normalize databases and found that WordPress works quite differently. All posts and all post types share a single table. All additional information is kept as metadata and then taxonomies be used for relationships and categorization. So I can understand this approach because it does provide that great flexibility the WordPress is known for but we did eventually run into problems building applications. So back in the beginning the idea within the WordPress community was that the use of custom tables was bad. And I agreed and I had a philosophy that you should always do things the WordPress way. I essentially felt that writing any kind of custom SQL should be avoided unless absolutely necessary. And to be honest I thought this was the correct idea and things were fine so long as their applications were small and straightforward. So that TV infrastructure project I mentioned earlier had many custom post types that were arranged in the hierarchy here. Now don't worry about trying to understand all of that exactly that's just to exemplify the relationships between these objects. So originally to avoid redundant data we only represented relational connections on one of the objects. So by that I mean if you have a contact here down the bottom we would only store its connection to the email campaign so it knows who its parent is. Now this connection was done either using metadata or post to post but that's not that necessarily relevant. Now we felt this was the right decision because it helped reduce the amount of redundant data but we found that this actually blew up in our face as things got more complicated because all of a sudden we needed to create these pages that pulled a lot of more data and we had to move up and down and around within this hierarchy multiple times on each page either in a query or in the code. So as an example of this if we're back on the contact we want to quickly grab the region that's associated with that contact we had to grab the email campaign then we had to grab the action plan and then we had to jump across to the region. So doing this 30 to 60 times on every page resulted in some performance problems. So for the following project which was like an event ticketing site we got around this by kind of biting the bullet and deciding to have redundant meta values on each object so that we could quickly traverse the hierarchy. So up the top that's just an example of the same hierarchy and then down the bottom is how we connected each of the objects individually which I know anyone who does database design would cringe at the idea of that. But the advantage was if we had say a sold ticket we could very quickly check its booking, its invoice, the event it was associated with or even the ticket that it was purchased from without having to pull any additional information from the database. However, even this wasn't enough to save us and as part of this project administrators needed to pull real time top level sales data from across events and even compare two events simultaneously. They also needed to pull complete spreadsheets of information for an event. So if we had to generate an export of all the tickets for an event, for example we needed to include details not just from the ticket itself but from the event, its booking, its invoice, et cetera. So despite what others may have thought at the time or even now we agreed internally that perhaps trying a custom table could be the answer. So we introduced a lookup table that essentially has stored those relationships from the previous slide in a specific table. So using this table we were able to rapidly query all the details for a set of objects in one go making it possible to produce these spreadsheets without crashing the site. So over time we found that as the complexity of data increases the amount of data accumulated increases or as complex querying or reporting requirements come into play, custom tables can be advantageous. So from lookup tables to full blown custom tables where you store all of your post data in the one point I do believe at this point in time that there is a place for these in complex web application development within WordPress. It might not be the accepted way but the thoughtful use of them has allowed us to provide performant working solutions for our clients and we found that WordPress does handle them without much fuss. Just make sure you know what problem you're trying to solve for us, it's typically performance and do your best to get the data design correct from the beginning. So that's about it in terms of what I wanted to share about my story. I also have just some rapid fire pointers from about the past five years of things I just have picked up and things I would have loved to have learned when starting out. So I guess either if you want to take questions or I can just run through these, it's whatever it's up to you guys. Yeah, I'll just run through them, let's go. All right, so file and directory structure I think this applies to anyone who does any kind of development. If you're going to be playing around with the structure of your files I think no matter what you do just try and keep it consistent. Even if you do it differently on each project keep it consistent within each project. So I'd say try to make things as easy as possible for you to find things in a crisis. I still believe that keeping application logic and visuals separate is a good idea and I'll move on. So for data and databases whenever you're going to have to design anything that stores information I genuinely believe that working out the data design is the most important thing when starting out. It's worth the time and effort to get it right. I recommend you take the time to identify what objects you're working with what information you need to store. And I also think it's worth taking some time to consider any possible information you might want to store down the line six months afterwards that would have been good to have on board from launch. So I was watching Brandon's talk on GDPR yesterday and obviously I think you should be mindful of what information you're storing. So don't think you have to store everything but I think there are plenty of things that the client doesn't think of that they would definitely benefit from collecting from launch. So an example for this would be if you have some sort of manual approval process that has to take place for like a job posted to a jobs board it's a good idea to just store the time and the date that that job was approved. Even if the client hasn't asked for it they might one day might want to pull the report of this sort of information and it's so useful having it all in there from the beginning. If you're going to use custom tables like I said just make sure you have a specific reason that justifies the extra time and effort put into it and make sure it's easy for any other developer on the project to quickly create these tables and drop these tables on their environments either with a setup function or with an SQL file. If you're going to write custom SQL I still believe we should avoid it unless you absolutely need to. So make sure you have a specific reason something like performance or if you're interacting with a custom table. I think a good reason for this is that it's a lot easier for another developer who's familiar with WordPress to come along and see your use of WP query and manage that than having to manage your crazy custom SQL. WP query these days can handle a lot of the tasks you'll need it to do and it's good to get in the habit of checking the codex every time before you blindly decide to use custom SQL because it's a lot better than what it was when I first started out. So with your coding standards I think WordPress has their own standards if you're not aware I've got a link to them at the end of this thing I suggest you check them out but I also encourage you to extend them and find your own standards beyond that. I think when you're writing code you should let legibility shape the structure so I think it's a good idea to keep it consistent and concise and really make it as easy as possible to read in a crisis. And I also think the use of comments especially PHP doc comments are highly underrated and I would highly encourage you use them. I think if you're a developer or especially when you're first starting out everyone kind of wants to rebuild everything their own way from the ground up but the strength of WordPress really is in leveraging what it provides you to build whatever it is if it's a plugin or an application. So you've got custom post types and users and taxonomies I won't go into all the details but essentially everything you need is kind of already there so it's a good idea to take what exists maybe tweak it if you need to but keep things within the WordPress space. So the aim really is to try and spend your time focusing on the bespoke features of the application. I think you should leverage WordPress and as part of that you should leverage the community. So come up with your own list of trusted plugins obviously not using hundreds but keep, you know, have a nice short list but also try to remember that you're not lazy for using someone else's code and then also don't forget to check out the codex there's heaps of blogs and tutorials there's so many resources online to help you learn and pick up new things. Finally I just want to say when it comes to code and I guess our attitudes with it I'm not the biggest fan of the code as poetry remark but I actually think it's true in the sense that everyone writes it differently and I don't think anyone intends to write bad code and if people could be perfect I think they would be so I think it's always good just to be mindful of that. It's very easy to see everyone else's work which your own is inferior, even your own if you forgot you wrote it so just be mindful of that. When you're working with clients I just quickly want to say that I genuinely believe that maintaining a good working relationship with your client is actually the most important thing and I think you should focus on what the client needs not on what you want to do and remember that clients really don't care about a technically impressive solution as long as it's functional it does what it's supposed to do it's not like it performs well and it looks kinda nice. I think when you're communicating with people above all be honest people really appreciate it I think it's good to learn to push back against scope creep to speak up about concerns especially early on tell clients when things aren't possible or if it's too hard and beyond your skill level and especially tell them when you've made mistakes or if something's blown up. Clients appreciate regular communication so try not to give them a reason to reach out to you first for an update. When you're working on projects with clients I think you need to learn to accept that they're never gonna know exactly what they want when they first come to you and it is part of your job to help them through that process. Having said that no amount of scoping or planning or anything is ever gonna save you from the nasty surprises that creep in mid development and finally I'd say don't ever expect the client or trust the client to test anything you build because they really don't know what they're doing and that's fine that's not their job. Keep in mind that whenever you're doing estimates and scheduling that things always take longer than you think when I was at university I was told that when you come up with an estimate you should double it, double it again and then add half and I laughed when I first heard that but I actually think it is true and also remember as part of this actually that a working day very rarely contains a full set of productive hours. There are always distractions. You slow down in the afternoon. You're human don't try and think that you're a machine. Finally just with working with clients this is probably more for backend interfaces. I found that having an intuitive UI that's very easy to use and almost holds the client's hand is so much better than having some sort of quick whipped up UI and then handing them a manual because they never read it. So just in general I kinda wanna say don't be afraid to try things, to make mistakes and to find what works for you. Remember that a scrappy but working solution is better than no solution and that the perfect solution doesn't actually exist. When it comes to your skills I think you should work on both learning to prevent problems and solving problems because you'll be doing both of them for the rest of your career and that you need to learn to take ownership of your mistakes. So finally just remember that you're human. Look after yourself. Most of your problems in life are gonna be solved with good honest communication and finally when you look back at all you've done perhaps over the past five years just remember that the more that you cringe the more that you've learned and that's it. Thank you. All right time for questions. Raise your hands. Okay one up here. Good chat. Were you able to incorporate unit testing into your development process? No unfortunately that's something I really would have liked to get in. One of the major restrictions we've sort of had is a lot of the clients who you work for were building an MVP style like minimum viable product solution and so to be brutally honest a lot of the times they don't want to have that factored into the budget and then I don't like that and I wish we could change that as much as I try and push for it it never seems to happen and typically once what ends up happening is we hand over to the client we have a testing phase and that's exactly why I say don't trust them to test you've got to test it yourself because they just don't know and they don't care. If they test something and they say it's good and then it breaks and they come back and you say well I told you they don't care that it's like we should have built it right from the first place so I really wish we had unit testing that's not something we've done there's something we want to do I keep pushing for it and I know other people within the company want to push for it but at the moment no. You mentioned with the example of a booking system a fully normalised tables can you give an example of the elements in those tables please to an insane extent or just... No I don't want to it's been a long time since I've had to actually look up the proper definition of a fully normalised table and I had the fear that if I put that in the speech I was going to get picked up on this but I used to know if you asked me five years ago I would have known I can't tell you it's when I talk about normalisation essentially what it means is that all the structure in the database is set up correctly so there's no data redundancy that everything is reduced to the smallest possible like atomic level of information that it needs to be See you might have two different customers that both of them live in Station Street So you're going to have a table of streets and... No well that's what I mean so we don't have fully normalised database tables here we're not pushing for that sort of thing Yeah Okay Yes you have described the WordPress environment as probably not the most suitable for application development but how would you rate the combination of actually PHP which is not really a heavy relational database language to actually develop applications how would you rate the balance between UI which of course PHP will do combined with WordPress versus the difficulties that you had in database design and data querying storage So like the trade-off between... Yeah between those two Yeah so I think that's probably one of the reasons why we ended up well again it wasn't my decision but why we've stuck with WordPress because it does like it's I guess WordPress is set up in such a way that it'll do almost everything you need to do good enough and then the advantages of WordPress in PHP allow you to build out a lot of other aspects of the application really quickly So like I for one like I came from a .NET background briefly and so I understand that when you start a new application you spend so much time setting up the database setting up data access and all that sort of stuff and coming to WordPress it's like it's almost all automatically handled and then the way metadata works you don't have to worry about table structure and updating table structure and oh they want to add a new field now we have to redesign the database So like I think the great thing about WordPress with our clients and the situations we found ourselves in is that the trade-off has been good So you run into these problems with the database as things get much more complex and we definitely do run into it and we even have existing applications that we kind of need to shift into using more custom tables because they just cannot handle the load but even having even that being the case the trade-off is still positive in my opinion Yeah