WordCamp Sydney: 5 years of application development in WordPress
At WordCamp Sydney 2018, Scott Commins who is one of our Senior WordPress Engineers presented about his experience over the last five years, working at The Code Company as a developer, who works a lot on our custom functionality projects for WordPress sites.
You can view the talk below:
Transcript
Scott Commins:
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.
Scott Commins:
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.
Scott Commins:
So I’ve now been working with WordPress at this 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.
Scott Commins:
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 plugin or a number of plugins. So an application, by contrast, for this talk is something where the CMS functionality of WordPress is either not used at all, or it’s just a small part of the site.
Scott Commins:
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.
Scott Commins:
This information might then be fed to the packers in the warehouse to package 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 CodeIgniter and Laravel and Slim, and plenty more. So why would you pick WordPress? And also why would you stick with WordPress for five years?
Scott Commins:
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 nontechnical.
Scott Commins:
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 good is 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.
Scott Commins:
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 foundational 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 plugins and themes to speed up development.
Scott Commins:
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 it’s flexibility, especially as things get more complex. So like PHP, WordPress will let you get away with things that it probably shouldn’t. Its 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.
Scott Commins:
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 WordCamps I was lucky to attend, which was 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 fast and flexible bespoke web applications to solve real world problems for both small and large businesses. And 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.
Scott Commins:
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.
Scott Commins:
Now this makes sense, but it certainly wasn’t common knowledge to me or amongst my peers at the time, and my attempts 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 them all 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.”
Scott Commins:
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, 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.
Scott Commins:
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.
Scott Commins:
So theme or plugin, either option only felt about half right, and if I used them both I 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… Well, 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 forms, submission, and manipulating data.
Scott Commins:
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.
Scott Commins:
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 core 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 handles some kind of major component of the site.
Scott Commins:
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 theme.
Scott Commins:
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.
Scott Commins:
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 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.
Scott Commins:
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.
Scott Commins:
So after all 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 CodeIgniter. 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.
Scott Commins:
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’d typically create a theme, a custom theme to hold all of our templates and our front end stuff. So you can sort of see the breakdown there, and yeah.
Scott Commins:
So transitioning to this process allowed us to enforce a consistent file structure across all of our applications, and encourage the adoption of programming standards and patterns that we liked, such as object oriented, or we followed a fairly rough MVC 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.
Scott Commins:
But the application space itself still allowed for some flexibility, and developers still had liberties 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’re perhaps building a custom WP admin page you could put the assets in the application, and then if you wanted any kind of generic fallback templates or example templates, you could put them in the system plugin.
Scott Commins:
So as always, there were problems. So one of the big problems that we knew was going to 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, and we had to give it up.
Scott Commins:
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.
Scott Commins:
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.
Scott Commins:
Likewise 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 twenties with three different skill sets trying to solve a real world problem with a real world solution.
Scott Commins:
So I spent some time talking about structure, but I also want to talk about the database as well. So coming to WordPress, I was used to fully normalized 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 we use for relationships and categorization. So I can understand this approach because it does provide that great flexibility that 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.
Scott Commins:
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 as long as their applications were small and straight forward. So that TV infrastructure project I mentioned earlier had many custom post types. They 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.
Scott Commins:
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 in the contact and 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.
Scott Commins:
So for the following project, which was an event ticketing site, we got around this by 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 it was purchased from, without having to pull any additional information from the database.
Scott Commins:
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 to 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.
Scott Commins:
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.
Scott Commins:
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.
MC:
No, just run through them.
Scott Commins:
Yeah, I’ll just run through them, let’s go. All right, so filing 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.
Scott Commins:
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.
Scott Commins:
So I was watching Brendan’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 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 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.
Scott Commins:
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 the setup function or with an SQL file. If you’re going to write custom SQL, I still believe you 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.
Scott Commins:
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.
Scott Commins:
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’d suggest you check them out. But I also encourage you to extend them and find your own standards beyond that, and 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.
Scott Commins:
I think if you’re a developer, or especially when you’re first starting out, everyone 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 uses and taxonomies. I won’t go into all the details, but essentially everything you need is 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.
Scott Commins:
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 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.
Scott Commins:
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 is 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. 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 but your own as inferior, even your own if you forgot you wrote it, so just be mindful of that.
Scott Commins:
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 kind of 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.
Scott Commins:
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 going to 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 going to save you from the nasty surprises that creep in mid development.
Scott Commins:
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, 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.
Scott Commins:
Finally just with working with clients, this is probably more for back end interfaces, I’ve 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 want to 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.
Scott Commins:
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 going to 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.
MC:
All right, time for questions. Raise your hand. Okay, one up here.
Audience:
[inaudible 00:28:18] Were you able to incorporate unit testing into your development process?
Scott Commins:
No, unfortunately that’s something I really would’ve liked to get in. One of the major restrictions we’ve had is a lot of the clients who you work for who are building an MVP style 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. I don’t like that and I wish we could change that, but as much as I try and push for it, it never seems to happen. And typically 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.
Scott Commins:
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 to…” They don’t care. It’s like, “Well, you should have built it right from the first place.” So I really wish we had unit testing, that’s not something we’ve done, that’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. Yeah.
Audience:
You mentioned with the example of the booking system, fully normalized tables. Can you give an example of the elements in those tables, please?
Scott Commins:
Oh, no.
Audience:
Is it to an insane extent, or just…
Scott Commins:
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 normalized 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. Yeah, but I can’t tell you.
Audience:
So-
Scott Commins:
When I talk about normalization, 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 atomic level of information that it needs to be.
Audience:
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…
Scott Commins:
No, well that’s what I mean. So we don’t have fully normalized database tables here, we’re not pushing for that sort of thing, yeah.
Audience:
Okay.
Scott Commins:
Yeah, yeah.
Audience:
Yeah, so 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?
Scott Commins:
So the trade off between…
Audience:
Yeah, between those two.
Scott Commins:
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. 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 and PHP allow you to build out a lot of other aspects of the application really quickly. So I, for one, 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.
Scott Commins:
And coming to WordPress, it’s almost all automatically handled. And then the way metadata works, you don’t have to worry about table structuring, updating table structure, and, “Oh, they want to add a new field, now we have to redesign the database.” So I think the great thing about WordPress with our clients and the situations we’ve 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 need to shift into using more custom tables because they just cannot handle the load. But even that being the case, the trade off is still positive in my opinion, yeah.
