Successfully reported this slideshow.

The Evolution of WordPress Software Development

1

Share

Loading in …3
×
1 of 38
1 of 38

The Evolution of WordPress Software Development

1

Share

Download to read offline

Description

When you start to use WordPress as an application platform, one thing is very soon clear: WordPress defines very little base structure for your application code, where to put and how to write tests, how application is loaded, or for example how dependencies should be managed. Because of this, applications or just complex sites built on top of WordPress tend to get really messy.
There are application frameworks built on top of WordPress, but none of them seem to have wide enough use for to build any serious applications on top of. Until any of those gets wide-spread adoption, combining existing, non-WordPress specific PHP technologies as a custom solution probably is a more future-proof solution. We will be looking into one possible stack of technologies.

Transcript

  1. 1. The Evolution of WordPress Software Development Aki Björklund @akibjorklund
  2. 2. How do you organize your custom code?
  3. 3. Why?
  4. 4. I bet it is not pretty
  5. 5. WordPress offers no file/folder structure
  6. 6. WordPress offers no autoloading
  7. 7. WordPress offers no unit test framework
  8. 8. WordPress offers no dependency management
  9. 9. WordPress offers no [insert a “professional” software development tool here]
  10. 10. Probably it shouldn’t either
  11. 11. There aren’t any plugins you can install to get those
  12. 12. There are plugin frameworks and some site frameworks
  13. 13. They are not widespread
  14. 14. …thus not suitable as basis of significant applications
  15. 15. We could roll our own… or not
  16. 16. What can we use then?
  17. 17. Create a solution out of existing widespread technologies
  18. 18. Solution like that is on a stable foundation
  19. 19. I’ll introduce to you our stack
  20. 20. Yours could be different
  21. 21. Bedrock gives us a project structure, but not for your own code
  22. 22. Composer gives us dependency management
  23. 23. Composer PHP autoloader will load files when they are needed
  24. 24. Symfony’s DependencyInjection component lets us write loosely coupled code
  25. 25. PHPUnit and WP_Mock enable unit testing
  26. 26. WPlinth is our collection of base classes
  27. 27. About code organization
  28. 28. Site specific code lives in the mu-plugins folder
  29. 29. mu-plugins/app-loader.php
  30. 30. Example folder structure of the application /Connection /PostType /QueryFilter /Service /Taxonomy /Test Application.php
  31. 31. Classes inherit WPlinth base classes
  32. 32. Invest in some time to organize your code
  33. 33. No need to use all the tools mentioned here for all projects
  34. 34. Document your solution online
  35. 35. Let’s start building standards
  36. 36. Write code that you would gladly inherit from someone else
 10 years from now
  37. 37. @akibjorklund akibjorklund.com/2015/wceu for slides and more info

Description

When you start to use WordPress as an application platform, one thing is very soon clear: WordPress defines very little base structure for your application code, where to put and how to write tests, how application is loaded, or for example how dependencies should be managed. Because of this, applications or just complex sites built on top of WordPress tend to get really messy.
There are application frameworks built on top of WordPress, but none of them seem to have wide enough use for to build any serious applications on top of. Until any of those gets wide-spread adoption, combining existing, non-WordPress specific PHP technologies as a custom solution probably is a more future-proof solution. We will be looking into one possible stack of technologies.

Transcript

  1. 1. The Evolution of WordPress Software Development Aki Björklund @akibjorklund
  2. 2. How do you organize your custom code?
  3. 3. Why?
  4. 4. I bet it is not pretty
  5. 5. WordPress offers no file/folder structure
  6. 6. WordPress offers no autoloading
  7. 7. WordPress offers no unit test framework
  8. 8. WordPress offers no dependency management
  9. 9. WordPress offers no [insert a “professional” software development tool here]
  10. 10. Probably it shouldn’t either
  11. 11. There aren’t any plugins you can install to get those
  12. 12. There are plugin frameworks and some site frameworks
  13. 13. They are not widespread
  14. 14. …thus not suitable as basis of significant applications
  15. 15. We could roll our own… or not
  16. 16. What can we use then?
  17. 17. Create a solution out of existing widespread technologies
  18. 18. Solution like that is on a stable foundation
  19. 19. I’ll introduce to you our stack
  20. 20. Yours could be different
  21. 21. Bedrock gives us a project structure, but not for your own code
  22. 22. Composer gives us dependency management
  23. 23. Composer PHP autoloader will load files when they are needed
  24. 24. Symfony’s DependencyInjection component lets us write loosely coupled code
  25. 25. PHPUnit and WP_Mock enable unit testing
  26. 26. WPlinth is our collection of base classes
  27. 27. About code organization
  28. 28. Site specific code lives in the mu-plugins folder
  29. 29. mu-plugins/app-loader.php
  30. 30. Example folder structure of the application /Connection /PostType /QueryFilter /Service /Taxonomy /Test Application.php
  31. 31. Classes inherit WPlinth base classes
  32. 32. Invest in some time to organize your code
  33. 33. No need to use all the tools mentioned here for all projects
  34. 34. Document your solution online
  35. 35. Let’s start building standards
  36. 36. Write code that you would gladly inherit from someone else
 10 years from now
  37. 37. @akibjorklund akibjorklund.com/2015/wceu for slides and more info

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

×