Putting WordPress to Work
Meet Alain Schlesser, software engineer, WordPress consultant, and newly named CTO of the WP Developer’s Club. He’s incredibly smart, has a mesmerizing accent, and likes big dogs.
Join us in this episode as we continue the discussion about formalized education in WordPress and how his new role of CTO will help drive the future of WP Developer’s Club.
Carrie: Hey everybody! Welcome to officehours.fm episode #76. I’m your host Carrie Dils and today I might be a little language challenged. My English is never perfectly stellar but today my guest… it takes an extra bit for this Texan to say it right. I’m going to go for it and then give you the chance to correct me. Alain Schlesser.
Alain: Yeah. Very good!
Carrie: Yes. Nailed it! So yes, welcome to the show Alain. It is great to have you.
Alain: Yes. Thank you. I’m glad to be on.
Carrie: Excellent. Thank you for you guys who are tuning in live. If you have questions for Alain, you can send those on Twitter to #officefm. If you’re watching via the Google hang out you can ask via the Q&A app. All right. So we have no sponsors this episode. So we pay homage to no one but ourselves, so let’s get cranking with the good stuff. So we were talking a little bit preshow about where you are from and where you are now. You were saying you moved from Luxembourg to Germany due to the high cost of living.
Alain: Yes. I worked as a government agent in Luxembourg for more than a decade. Housing in Luxembourg is very expensive. When we decided that we wanted to change our lives, my wife and I decided to move to another country where the housing is much cheaper. So that we could have some more financial wiggle room to be able to build up something new before running out of cash.
Carrie: It sounds like a wise plan. Do you still have family back in Luxembourg?
Alain: Yes, but we visit them regularly. It’s only a bit more than an hour to drive to see them you know. So we’ll see them at least twice a month or so.
Carrie: Ok. Well I’ve got lots of questions for you. But before we go anywhere allow me to congratulate you on your new role as CTO for the WP Developers Club .
Alain: Thank you.
Carrie: Yes I was very excited to see that. For folks that may not be familiar with the WP developers Club, can you give us the rundown?
Alain: Yes. WP Developers Club is a very wonderful place that Tonya (which you had on your show two sessions ago I think) has created. It tries to address the need in the WordPress ecosystem for more formalized education for certification. It tries to push the envelope WordPress development forward in terms of software quality and in terms of what developers demand of themselves in terms of…how should I say this? WordPress makes it very easy to start but makes it very complicated to use best practices developed not all of the platforms It is very difficult to use such best practices WordPress platform. That’s where WP Developers developer’s school wants to help. So that people get to learn all the best practices. They get to learn proper software architecture, proper software development, object oriented programming principles and so on.
It’s a wonderful community that you can join for free. The major courses come with tuition but you can just join for free. There’s a lot of interaction going on. There are people of all skill levels that help each other out. There’s also a great sense of curiosity that comes across in this community. It’s a very inspiring place be.
Carrie: I’m excited about it. It might have been episode 67 that I had Tonya on. I’ll have to go back and look at that. So in your role as CTO will you be helping shape the course work or how does that fit in?
Alain: I have two main roles. The first is to do is to keep everything running from the technical side of things. Make decisions about the architecture to use and implement all the stuff that needs to be implemented. The other is to help shape the code base on which the whole site runs, which is also the example that is made to show people what a proper code base should look like for a WordPress site. So on waiting on the code base to be built. It has already been built for the WP Developers Club. It is a set of code base to be used as an example for the courses. The courses themselves are built by Tonya. She’s also the main teacher. There are also workshops that will be added at a later point in time where there will also be other teachers that teach courses in different areas. The main course work will be built and taught by Tonya.
Carrie: Well Tonya is going to run out of Tonya. So I’m glad she’s bringing on some help to help flesh out that the WP Developers Club. So if you’re listening to this and you haven’t checked that out yet, go over to WPdevelopersclub.com. Like Alain said, it’s free to be a part of that. Yes. With Slack, I’m more of a lurker rather than participator over on the slack channel.
Alain: I see you in the comments sometimes. Lurking from the outside in.
Carrie: I lurk and then when I have questions I jump in. I just take, take, take. Ok. So Gary wants to know have you ever entered a David Grohl look-alike contest? You do bear a striking resemblance to Mr. Foo Fighter.
Alain: Ok. That’s a bit less of a technical question that I anticipated from Gary. I am out of answers now. No. I didn’t attend a contest like this.
Carrie: Well you could be a model.
Alain: I am not a great singer.
Carrie: All right. Well maybe you could do a lip-synch kind of thing. I don’t know. We’ll put that on backside if we’ve got time at the end of podcast. Thank you Gary for that insightful question. Jackie is asking any thoughts on PHP7 and how it will impact WordPress and coding standards? Great question Jackie.
Alain: Yes. PHP7 has a few new features that are really great to be able to build a more robust code base. One big changes is that you can return for example, type in and you’re return values. The function that you develop can tell other functions what type of object or variable it will return. So you’ll get immediate errors when you have a mismatch in there.
Carrie: In terms of data type?
Alain: Yes, you’ll get a type mismatch error or an exception gets thrown. This sounds really bad when there’s errors flying around but normally in development you want to have real hard errors all the time. You don’t want something that runs normally but sometimes it breaks – sometimes it works and you really don’t know why. Normally you want to build your code so that when there’s a potential error there’s immediately an error that gets thrown to pull your attention to the area where the problem lies. Because when you have a code base that runs but does not give the right output you don’t know really where to start to debug it.
Carrie: Yes. The worst possible…I used to be on Windows machines. We were talking about this preshow that you just recently switched from Windows to Mac. But on Windows machines you would get the most useless error message ever. Like it does not work. Something so generic and nonspecific that it was difficult to trouble shoot. So good on the specificity.
Alain: The worst problem that you can have with WordPress sites is that you build something. You run it and simply get an empty page without an error message. So if you have something like this you don’t know where to start. This one of these best practices is that you always want to build your code so that it has very strict requirements that it immediately breaks when you don’t need these requirements. You want everything to fail fast and to fail hard. It’s sounds really bad but it saves a lot of time debugging.
Carrie: Backing up just a little bit, Davinder had a question. He says when you refer to building your code base, are you referring to building WordPress themes or more of your general PHP/CSS workflow?
Alain: The code base I was mentioning earlier. The codebase is a combination of everything that makes up the site. When you build WordPress, it’s just one component of the entire system. You have a lot of plugins. Some are premade and some custom built. From a complex site, you have a theme, you may have additional databases that are running somewhere. You have media assets and so on. So you could say WordPress is just one of the many libraries you use to build a website. So the PHP code is a lot of plugins that you run because that is a way too to extend WordPress without modifying the core source which would break updates. Of course you the theme with every site that you want to make public. There also might be integration code for example if you have some data somewhere in another system you’ll need to write integration code that gets data from one server and translates it and puts it into the database or meta server. For example, a system to auto invite people to sign up to select. That’s one simple example of such integrations. They always have code that makes the bridge between WordPress and some other system that gets intergrated.
Carrie: All right. Thank you Davinder. I hope that answers your question. If not feel free to send it again. We’ve got a question from Robert. He’s asking that so there’s a elementaries course over in the WP Developers Club and when it opens with her more than 10 people be let in or is that a hard maximum?
Alain: There is some good news. The elementaries course will be free. Tonya intends to have the elementaries course as free because it is so valuable to the community. It’s sort of an entry point to see where this might take you and you will be able to evaluate the quality of the course. Then there’s the Dev Apprentice Program. That’s limited to 10 participants per session.
Carrie: That makes sense because there’s a lot of actual one-on-one as opposed to a video that is consumed by many.
Alain: Yes. The elementaries course is mostly theoretical stuff. You can go through the videos and read through the course materials. The Dev Apprentice program is two main parts. One part is a learning stage where these 10 people will all build the same website and get a companion to build this. Then there’s another second stage where it’s planned that the participants can build a real site for a client of theirs with guidance and mentoring along the way. I can’t hear you.
Carrie: Sorry. I had the wrong button there. That’s very cool to get that real live example. Sometimes working sample code is one thing but actually putting it into the context of a real project is something else. That sounds very well worth it.
Alain: It does. There are still some details that we need to flush out. The planned projects also need to fit some basic requirements so that this can work. The main plan is to go through the entire Dev Apprentice course you will have created as much value as the course has cost you.
Carrie: Awesome! That’s called value pricing right there. So Jackie. I think you you know the answer to this question but I’m glad you’re asking it anyway. Typically when you’re first learning how to modify Genesis themes or any theme in order to make a child theme you open up functions.php and shove all customizations in there. Which obviously can get a little out of hand depending on how many modifications there are. Jackie’s question can you talk about building a core plugin and why that’s better or if it’s better than adding code functions.php.
Alain: Yes. The core plugin has one main advantage. It is 100% reusable. It is a library of code that you could put as it is into your source control. Pull it in for a project when you see that there are some things missing you add them to this core plugin, push these changes back to your source repository. You can run an update for all your sites that just use core plugin and this enables you to grow your core plugin overtime. You get more and more efficient building client sites because there’s more and more code that’s already prebuilt in your custom plugin. Your theme will reuse this code and will simply add the things that are site specific or project specific. For example: instead of a having all the code that creates a specific custom post type, you’ll have functionality in your core plugin that registers the post type that has all your custom stuff to adapt the admin backend for your clients. It has the ability to sort, to filter… I am not sure what else you could add as features. In your functions.php file you need to have one line adding custom post type of type X-Y-Z and you’re done. If you find a bug with your code you’ll have to make one change and simply push this new version of your plugin to all of your clients sites. You can debug all your sites with one push.
Carrie: Ok. Let’s take that a step further. I have used the core plugin concept on a number of projects and recently somebody brought up (it might have been Gary Jones) of abstracting even your core plugin into little individual plugins. So say that each plugin stands alone. So this is a plugin that deals with custom post types, this is a plugin that deals with your meta boxes and etc. etc. etc. versus having them all lumped into one. What are your thoughts on that?
Alain: This might make sense depending on what the scope of your core plugin is like. But I think that Gary wasn’t talking about plugins but about objects.
Carrie: I do see a comment from him. He says with core functionality you better have separate composer packages pulled into a core plugin.
Alain: Yes. You would have different objects. One object to deal with a meta box and one object to deal custom post types. With objects you can have them included through composer and composer will also deal with the auto loading. Auto loading is a mechanism in PHP that allows you to just say what class you want. The class is a blueprint for an object. The autoloader will try to find a file for you. Normally you’ll have your PHP files full of retrys and includes if you split it up into many different files. With classes and objects with an autoloader, you can get rid of all of this. You simply will tell composer to add your metabox package and in your plugin you’ll say metabox is a new metabox with these arguments. The autoloader will manage to include the class file so that you don’t have to do deal with this. One of the main advantages of this is a performance benefit. You can put 100 classes into your packages. If you use one class only this one class will get included. Only this file will be processed by PHP. All the others will not be touched. So you can have a large library of prebuilt functionality and only use the ones you need without having a performance impact.
Carrie: While we’re on the subject of performance I had a great question from Teresa. When you first start learning WordPress. Get all plugins! No need to write anything myself. I’ll get plugins to do it. At some point you learn enough to know whoa! Too many plugins is terrible! You shouldn’t have 80 plugins. But the fact is a plugin itself…it just depends on whether it’s a well written plugin.
Alain: The number itself is irrelevant. If you have plugins that are properly coded they have exactly the same performance impact as if you would put everything into one file or if you would put it into WordPress core. If the plugin is properly coded it will have no performance impact at all. The problem with plugins is that most of the time they are badly coded. Most often you’ll have plugins that do some stuff on the front end. For the front end you’ll have to include your sets. You’ll have to include stylesheets and JavaScript. If you have a 100 plugins installed, each include their style sheet. You’ll have 100 different small style sheets that get loaded through the HTTP protocol. So that’s a huge performance impact. Of course you can always do some performance optimization after the fact. For example taking all these stylesheets then concatenating them and putting them into one mini file stylesheet. That’s not an optimal solution.
Carrie: So assuming the plugins are well coded. We’re not calling in the references to a million external stylesheets. Is there any performance difference if I took that code that’s in the plug-in and plopped it into functions.php? In theory.
Alain: If there are no major differences in the way it is called or activated it will not will have a noticeable performance impact. It might be a small performance impact the first time you run it because there’s one file the server needs to retrieve. But these are not things you need to worry about when it comes to performance. When you have your Internet connection your bandwidth is completely wasted because there’s a dozen files that get loaded without being needed. We’re talking about entire seconds here. So if you can avoid a millisecond on the server file access, that’s completely irrelevant. So having a plugin or having a function in functions.php makes no real difference.
Carrie: Well in Texas we would say there are bigger fish to fry when it comes to performance.
Alain: Exactly. Optimizing always needs to start at the high level; from top to bottom. You don’t start with some meager file access somewhere to start optimizing because it will only complicate your code and make the more important optimizations more difficult.
Carrie: A question going back to where you mentioned that you could have a core plugin that you could automatically push updates to multiple client sites. Jackie asked how do you handle pushing those updates?
Alain: That’s a great question. That’s one of the problems that still remains to be completely solved with WordPress. There are a lot of interesting ways to go about this but there’s “no magic bullet” as far as I can tell so far. You’ll always have to deal with differences between hosts. For example: a git push will do nothing if the server doesn’t have git installed. There are ways for example to use a CI system…to let the CI system build everything and put it on the server with ftp. But again the server may not allow this. There is no one solution that will fit for each client because most clients come with their own hosting, their own requirements. Although we’re talking about the theoretical benefit here when I say you can update all of your sites. It’s more you can update multiple sites at a time. I am going to rephrase it like this.
Carrie: Fair enough.
Alain: You have to look at everything from the server that does the hosting, from the source repository and the whole team that works with you. There would be methods to be able to achieve this completely. In reality we will probably ever reach scenario.
Carrie: Davinder did remind me over on Twitter that if you’re using EDD easy digital downloads…their software licensing tool…you can actually set it to push updates. But of course that would be more for if you’re offering a premium plugin or something. I could see that being a good solution. Phil asked can you recommend some resources for learning object oriented programming?
Alain: The best resource is Uncle Bob. That’s Robert C. Martin. He is one of the best-known thinkers in the object-oriented world. When you’re talking specifically about PHP it gets a bit more difficult because in the PHP world there are a lot of major differences between object-oriented programming in a dynamically typed language and in a statically typed language. If you look at the code in Java or C++ which are statically type languages there’s a lot more going on than there is in PHP. If you simply use this code, which normally most of the material you can see online that teaches object-oriented programming would probably use constructs from Java or C++. If you use code like this in PHP it will be unnecessarily complicated and you will have more trouble making it work than is worth the hassle. If it is properly implemented, PHP is actually a very convenient language if you use object-oriented programming because of the dynamic typing it lets you take some shortcuts that still allow you to use object-oriented programming while avoiding the strict rules that make such complicated code necessary (like in Java). I know of a few people who do a lot of great interesting stuff online. I don’t know if I can pronounce the names and can get them correct. Perhaps it might be easier if write a few references for the show notes later. I know Carl Alexander is writing a book specifically about PHP and object-oriented programming. As far as I can tell from his blog that it will probably be good stuff. There’s one that Gary Jones recommended to me but I can’t remember the name.
Carrie: Gary? Throw it out there on Twitter.
Alain: It was Brendan…I can’t remember his surname…he has also written a book specifically about PHP and object-oriented programming. But good material in the PHP world is very rare because it’s a recent evolution for PHP itself. Most people working in PHP for a long time.. whenever the situation was where they could learn object-oriented programming…PHP before version 5 would not allow writing proper object-oriented code.
Carrie: Hmm. Gary chimed in and he said that is Brandon Savage that’s working on the other. Tonya’s chiming in. She says that Dev school will teach you object-oriented programming.
Alain: Of course.
Carrie: You can’t miss the chance to throw the sale in there.
Alain: A marketing opportunity there.
Carrie: Tonya knows how it’s done. So Leonica asks do you have any resources on core plugins? Are there any? I don’t think I’ve seen any resources on core plugins. But just how learn the concept or would you suggest just going and then looking at some that already exist?
Alain: As a core plugin not necessarily because these are very personal projects. It’s something you build to adapt a normal programming environment to your preferences. So I don’t think you can easily share most of these core plugins between developers because it misses the point. However, I want to add that you should not only look into core plugins because a plugin is only one method to integrate reusable components. In WordPress we constantly use plugins for all sorts of stuff. You could, for example, also have a core library that gets included in all of your plugins. It does not necessarily need to be a separate plugin. A separate plugin allows you to use it as a must use plugin for example. That’s one of the advantages but it also might be beneficial to have common core code inside a library instead of plugin depending on how you prefer to work.
Carrie: Interesting.
Alain: What is very interesting in recent PHP development…it’s not so recent but it’s take some time to really get used a lot in the WordPress world…it’s composer. Composer is a package management for PHP. You can, for example, have a personal Git repository somewhere and that you can simply pull in from composer. So when you create a new plugin, there’s one line in your composer.json file that references your core functionality Git repository for example. Then it gets simply pulled in. If you make changes to this Git repository and you do a composer update, you’ll always get the newest version of this. That is another way to build a reusable component. The main word I want to stress is reusable. If you want to progress as developer you have to make sure that you build your own code base as reusable as possible. The worst thing you can do is start fresh from scratch with every project. Then you will always stay at the same level. If you manage to build reusable components you will always be able to advance from project to project. You’ll be able to take on more complex, larger scope projects given time.
Carrie: That is excellent advice. We have a question here from Jackie. She’s asking if you’re doing a core plugin for a client would you make it a must use or new plugin?
Alain: This pretty much depends on what exactly the size of the infrastructure that is built. There are sites that contain a lot of custom functionality where you’ll end up with 20 plugins which contain different modules that you have to build to have custom functionality. That makes sense to have a core plugin that you’ll add a must use where all the other modules depend upon it. If you have a website that is a standard WordPress blog with one custom functionality it would make more sense to build one plugin that pulls in your custom code as a library and is independent of everything else.
Carrie: Yeah. I guess if you have a plugin that’s a single point of failure if it’s not active that would definitely be one that you’d want to use in a must use. Let’s see. We’ve got all kinds of good questions. Thinks everybody for sending these in today. Davindor is asking if you’ve used either Joomla or Drupal. If so, do they offer a better code base then WordPress?
Alain: I’ve dabbled in both just to evaluate the platforms to see if they are interesting to me or to the way that like to work. I would say that both of these are much more difficult to maintain. The way they are built makes it relatively easy to have a site set up once with your custom look. It’s easier to have some custom look in there as it is with WordPress. But the larger a site gets and more complex a site gets the more you’ll have trouble maintaining it the more expensive it gets to make additional changes. They are both very bad at scaling. The working hours you’ll have to invest to grow the site. With WordPress, it’s not exactly linear but if you have a large site and you want to add functionality it’s not much more complicated than a small site. There’s no big change. There are more things you need to be aware of but it’s not exponentially more work to do it.
Carrie: Interesting. I’ve never worked with either. I know generally speaking people who worked in Joomla or Drupal tend to look at WordPress developers as sort of the nursery school of development. So I wondered what was going on in terms of sophistication of those code bases that would cause people to have that opinion about WordPress.
Alain: WordPress has a very low barrier of entry which is a blessing and a curse at the same time. It allows everyone to be able to just use the five minute install and get going with their blogs but it also means that you have million blogs that teach you how to do things in WordPress the wrong way. So it’s difficult to find good advice for WordPress because there are so many people that were just playing around with it for some hours and then sharing their advice. It’s a nice thing that they want to share their knowledge but it’s because the barrier of entry is so low that there are no safeguards to keep people from posting horrible advice.
Carrie: Well WP Developer Club is most definitely raising the bar in that department. I love seeing it. Gary has a question here for you. Can you explain the benefits of moving away from the default WordPress structure i.e. Bedrock and WP starter? That might have been a loaded question.
Alain: Yeah. The way WordPress is normally installed is very bad for deployment. In its default installation makes a proper deployment path impossible.
Carrie: Sorry I’m interrupting you. Is that due to the database and the way the data interacts with the files? Or just in general.
Alain: The database is always a separate issue from the file system. The database always needs special consideration for deployments because of the way it is installed. We’re talking just file system structure. How the files are all layed out. The normal structure that WordPress uses mixes all sorts of stuff in its hierarchy so that you can’t separate the stuff that you build from the stuff that comes with WordPress. So for proper deployment normally you’d have your source version of the site, which only contains the information that is specific for your site. Then you ought to have a build system that uses the source and builds the completed site. As I already mentioned earlier WordPress is just one component of the final site. So in a proper deployment system WordPress would be a dependency of your custom built site. It would be pulled in as a dependency just as your plugins that come from your WordPress repository or anything else you can use as a dependency. When you switch the folder structure around for WordPress you can get closer to this proper deployment path. You can have one folder where the code base for WordPress that is a WordPress call with all the files that come with it and you have another folder that contains all the custom definitions for your site. In other languages often this is called the app versus the library or the web server or whatever. So WordPress is only a dependency of your site and you’re not building something inside of WordPress. You’re building something that uses WordPress amongst other systems to have a completed product. If you switch these around, as you can see examples with Bedrock that Gary mentioned and the WPstarter repository from We Code More in Github. Both address the same issues with different ways to go about it. Bedrock uses an ansible playbook. It means this is a script that gets run to build the entire site in an automated way. So you can a script to a server. The script goes to the server and installs everything that is necessary for the site with WordPress being one of the dependencies. The Linux call and the engine X webserver are being other dependencies. It is all automated until you end up with a final site. The WPStarter repository is a similar thing but using composer – the PHP package manager and pulling in WordPress as one of the composer dependencies. So composer is just a package like Yoast SEO or something else that is reusable and is all ready made up. You’ll end up in your Git repository with your custom-built source code and your composer.json which details all the dependencies that your custom code has. When you run the composer install everything gets automatically downloaded and installed with WordPress being one of the many packages that get pulled in. You can automate your entire build system. When you have a new developer on board, you will do a get clone of your repository, then run composer install inside this repository and then he has a local working development machine that runs the site.
Carrie: So for you guys that the listening that took my WP Development Workflow course..imagine you’re using Grunt and you have your package.json file that has all your Grunt dependencies listed in there…then you run one install and it just brings in each of those packages. Alain, so what you’re talking about is just that concept but on a much broader level, where WordPress is just one of those dependencies.
Alain: It’s the same concept. You just to need to do some extra magic to get WordPress to fit into the system that everyone else uses pretty much. When you’re using your package.json file this is the package manifest for the MPM package manager. Which is the package manager for node.js. Composer has it’s composer.json file which is the same mainifest just for the PHP package manager composer. So MPM and composer are equals in different languages.
Carrie: Awesome. Thank you for clarifying that. You’re going over my head so it’s possible that you’re going over some listener’s heads too. I’m going to have to go back and listen to this episode and then just sign up for WP Dev school.
Alain: That was a nasty question.
Carrie: No it’s fantastic information. It’s nice to get out of the rut of the things you are used to and see what more experienced developers are doing. So thanks for letting us peek over your shoulder. I was going to ask…in the case of a complicated build where WordPress would just be one of many things…can you give an example of a project that you’ve worked on that was…we’re not talking mom and dad’s ice cream store’s blog for this sort of implementation. So what kind of site are we talking about?
Alain: This is nice to have if you’re doing solo projects but it really only starts to make sense if you’re working in a team. Because when you’re working in a team it starts to become very time-consuming to let new people doing development work to get them up to task. To have them set up with a working environment where they can finally start to code. In such a team, automating all this work of setting up the environment can save a lot of time. Where it also make sense is if you have very specific requirements for the deployment because when you have such a system in place to build the development environment in automated fashion it’s just one extra step to have deployment to live being automated – to staging or to live. You can for example have a build system that will create a new vagrant virtual machine with your development environment when you tell it to install dev. When you tell it to install live or staging it will create a new digital ocean droplet where it will do the same process and you’ll have a live server online that was built in an automated fashion. When you do CI continuous implementation there is a requirement. This means that there are constant builds that are being done of the code base. And the code base that is in repository…for example the master branch should be buildable and testable at all times. So you’ll have a CI system that contains all the build steps in place that can run the entire build process on its own. For example, with every git push to the master branch it will run a complete build, run all the tests and immediately tell you if your last commit has introduced breaking errors or had problems that made tests fail or something like this. You can automate this process that when you do a git push you’ll have all the tests run. And if all the tests succeed this gets automatically pushed to the live site.
Carrie: That’s awesome. I’m imagining the all the things guy saying “Automate all the Things!”
Alain: In traditional software development releases are always months or even years apart. You’ll have version 1.0 which works somehow and then six months later there comes version 2.0 which is already a bit better. With a web app for example, if you have software as a service that people use live, normally you’ll have a system like this behind it that allows you to release very often. So you can release new versions of the software daily if you want. So when people tell you ok there’s this little feature that’s missing or this little bug that is making me nuts…it’s a matter of days to have the new release live that fixes it.
Carrie: Very cool. Ok guys if you’re listening live you’ve got time for one or two more quick questions. In the meantime thank you for tuning into officehours.fm. You’ll be able to catch a replay of this episode over at officehours.fm or over on YouTube or over on Google+. Check the officehours.fm community over there. I’m all over the place. If you would like email reminders of upcoming episodes, just go to officehours.fm/subscribe and we’ll get those taken care of. By the way Alain, I apologize for the chronic misspelling of your name. Can we just blame it on El Niño or the weather…or my being Texan, I don’t know. Davinder says I need to speed up my PHP movement. Lots of stairs yet to climb. Thank you for the inspiration. So yeah. You’ve given us a lot to noodle on and have shown us that there’s a lot more than the cookie-cutter WordPress functions.php plugins world that we’ve just kind of grown used to. Not that it’s bad. It’s just there’s a lot more that we can utilize WordPress.
Alain: I noticed the difference between backgrounds where people are coming from when they start working in WordPress. A lot of WordPress folks have design backgrounds. So they approach building websites as a designer which is a great thing. I have another background. I approach the whole thing as a developer. I can also do design but that’s not always the best use of my time. Let’s put it that way. I’m more of the developer and I had the opportunity before working in WordPress to see how things are done on other platforms and other languages. It’s always a good idea to look outside of your current platform and see how other people are doing it because there are a lot of approaches that can be transposed to the WordPress ecosystem. That’s one of the things that we trying to do with the WP Developer’s Club is to use these best practices that have existed for decades already and introduce them to the WordPress people that don’t have this developer background.
Carrie: Excellent advice. We’ve got one more question. Jackie’s getting on in under the wire. She asks can you recommend any tools automate importing a static HTML site into WordPress? Whoo! I don’t know about that because there’s the data piece of the puzzle you’d have to address. I’m stumped. You have anything?
Alain: In a static site, you don’t have any data. You just have HTML. You can always use a subfolder somewhere and do your install and use some rewrite rules magic in your HT access or engine X file and directly point at that these files. Properly integrated them into WordPress you could load them in as pages. Create a page template that pretty much gets rid of everything that’s WordPress specific (site, header or footer) and only displays the static page full screen. That would be one way. I’d say it depends on the exact use case.
Carrie: Yeah. I would say scrape the data and just rebuild the site from the ground up.
Alain: Probably when we would talk about a real use case probably I would say that it’s missing the point of WordPress. It really depends. If it’s a legacy site that you have to load into there that you can’t really use WordPress for there are ways to do this. But will it will never be elegant. WordPress is not meant to have something like this. It would either be rewrite rules that point to a folder or manually editing the pages.
Carrie: All right. We are up. Time is up. Thank you to those of you who are tuning in live. If you’re catching this after the fact I really appreciate your listening as well. If you enjoy the show you are always more than welcome to leave a kind review over at iTunes or Stitcher. Alain. Thank you so much for your time. You are a veritable fount of knowledge. Where can people find you if they would like to follow up with you?
Alain: I’m trying to be more active on Twitter. At the moment you can see my Twitter handle on the bottom @schlessra. But I have started a personal blog yesterday or so @Alainschlesser.com. You should take screenshot because it’s very difficult to write the name properly. I can be found in a lot of select groups like the WP Developers Club of course. Also the Genesis WP select group and I have a website where I focus more on the business side of things @brightnucleus.com which is in desperate need of a redesign.
Carrie: Ok. No shortage of ways to find you. Thank you again so much and everybody tuning in. We will see you next week. Bye!