Successfully reported this slideshow.
Your SlideShare is downloading. ×

Modern websites in 2020 and Joomla

Upcoming SlideShare
A Day of REST
A Day of REST
Loading in …3

Check these out next

1 of 45 Ad

More Related Content

Slideshows for you (20)

Similar to Modern websites in 2020 and Joomla (20)


Recently uploaded (20)

Modern websites in 2020 and Joomla

  1. 1. George Wilson - December 2020 Building Modern Websites The Cloud, APIs and CLIs
  2. 2. • Senior Consulting Engineer @ Automation Logic • Working in DevOps on Government Projects • Joomla Leadership 2013-2019 • Joomla 4 Release Lead • Please feel free to reach out on: • Glip: George Wilson • Email: • GitHub: wilsonge About Me
  3. 3. • Many people reference Google trends as a measure of Joomla’s decline • No one mentions Wordpress in the UK is down ~50% in Google trends over the last 5 years • Partly because their GLOBAL marketshare remains constant • Why have many companies and agencies have fallen out of love with the traditional PHP CMS’? Where did this talk come from?
  4. 4. The Cloud
  5. 5. • Ultimately any group of servers containing applications and databases is a cloud • Traditional PHP Shared hosting by <insert you hosting provider here> is a cloud • But these days the cloud o ff ers so many more services than just a hosting platform • Machine learning • Secrets Management • Storage • CDN • Container Management • Virtual Machines So what is the cloud?
  6. 6. Why are People Using the Cloud • Depth of services • Costs/Scalability - Pay for what you use and scale it as required • Flexibility • Reduced Downtime • Great disaster recovery options • Excellent Monitoring Capabilities • Serverless
  7. 7. • These days people are tending towards one of the 3 platforms: 1. AWS ✦ General Purpose, often small business 2. Azure ✦ Often more corporate based as more transparent on it’s security model 3. GCP ✦ Highly data focussed - many optimisations for large data sets & analytics The Modern Cloud Source: cloud-architecture-on-aws-a-concepts-series/
  8. 8. • Amazon’s Off ering • Dozens of services baked in - but generally speaking a PHP Environment might look like: • VPC (Network) • S3 (Storage) • EC2 (Linux VM) • RDS (MySQL) • Route 53 (DNS) AWS
  9. 9. For when that sounds like too much Elastic Beanstalk
  10. 10. For when that sounds like too much Elastic Beanstalk 15 minutes later…
  11. 11. For when that sounds like too much Elastic Beanstalk Around $19 a month including a HA Database
  12. 12. Caveat This just helps you to get a working setup in AWS this isn’t for use in real life!!
  13. 13. • People no longer use static con fi gurationfi les • Lack of portability between environments • Desire to automate creation of environments in ever simpler ways • .env project • Pulls in from environment variables OR from fi les • Used in most modern PHP projects notably Laravel • Would allow full use of Joomla in a Beanstalk project Modern Configuration Files
  14. 14. Quick Format Comparison Joomla - Global fi le containing prod values. Values assembled from con fi g object as required Laravel - .env fi le containing dev values, then assembled into con fi guration fi les which in turn are loaded into a Con fi guration class
  15. 15. Things we can do in core about this compare/4.0-dev...wilsonge:feature/dotenv? expand=1
  16. 16. Managing Installation/Updates • So in summary: • We have a Linux machine which gets destroyed and rebuilt every time we make a new deployment from our ZIP fi le • Questions Remaining: • How do we disable use of Global Con fi g in the UI - these values are no longer con fi gured through Joomla, but by our environment variables • Same sort of switch required for loading our .env fi le for local development • How do we manage the installation process (given all the normal form fi elds are useless) - but we still need to setup our SQL DB? • How do we manage Joomla upgrades - committing the physical fi les to git is annoying
  17. 17. Automating Things • My job is to automate the creation of resources • In the words of a former team lead “You really hate GUI’s don’t you?” • We’re going to use two tools for this • AWS CLI (v2) - Installation Instructions: userguide/install-cliv2.html • I have authenticated to my personal AWS Account already • JQ - JSON Parsing for Bash - • We’re largely going to follow the tutorial documented here https:// but being a bit more speci fi c to deploying my dummy Joomla instance
  18. 18. Automating Things • aws elasticbeanstalk create-storage-location • aws elasticbeanstalk create-application --application-name george-joomla-cli • aws ec2 import-key-pair --key-name "george-primary-laptop-ssh" --public-key- material fi leb://~/.ssh/ Ensure that a storage location has been setup Create the main application (empty at this point) in Elastic Beanstalk Setup my public ssh key into AWS for use later
  19. 19. Automating Things • aws s3 cp build/tmp/packages/Joomla_4.0.0-beta6-dev-Development- s3://elasticbeanstalk-eu-west-2-846108235618/test/ • aws elasticbeanstalk create-application-version --application-name george- joomla-cli --version-label v1 --source-bundle S3Bucket=elasticbeanstalk-eu- west-2-846108235618,S3Key=test/Joomla_4.0.0-beta6-dev-Development- Name of storage location from previous step Path we want to drop our data in - can be anything we just need to remember it for the next step! Copy our zip that we want to deploy into the above storage location Now upload our local copy of Joomla upstream
  20. 20. Automating Things • aws elasticbeanstalk list-platform-versions -- fi lters 'Type="PlatformName",Operator="contains",Values="PHP"' | grep PlatformArn | awk -F '"' '{print $4}' | awk -F '/' '{print $2}' • aws elasticbeanstalk create-confi guration-template --application-name george-joomla-cli --template-name v1 --solution-stack-name "64bit Amazon Linux 2 v3.1.3 running PHP 7.4" Check what PHP Versions are available for us to use - Source:
  21. 21. Automating Things • aws elasticbeanstalk create-environment --cname-pre fi x george-joomla-cli -- application-name george-joomla-cli --template-name v1 --version-label v1 -- environment-name v1-initial --option-settings fi le://options.json Create the environment - start with a simple con fi guration! Setup networking (not required in some cases) Required permissions for EBS to connect to our Linux Box Ensure our Linux Box gets a public IP address so we can access it through the browser Ensure our SSH key can access the Linux Box
  22. 22. Automating Things How to fi nd out what the magic options are? • Google -> AWS Documentation :) • options-general.html
  23. 23. Settings in your Github Repo! • Not all options have to be con fi gured in this JSON fi le! • Some options can be controlled in your GitHub repo • Environment speci fi c things will need to be on the command line still • MySQL Database: Environment JSON File • Joomla Site Name: con fi g fi le in repo Automating Things Source:
  24. 24. Summary • We setup a fully automated Joomla environment with just 7 commands (and 1 json con fi g fi le) • This means we can spin up our environment in a public location again and again (and delete it on repeat) at will • We also have good visibility over the environment (in a way we wouldn’t have on a traditional PHP host) Automating Things
  25. 25. Cli Control Source:
  26. 26. … and why should you try it? • Many people have been getting back into CLIs • Development with git • Containers with docker • Companies are making automation a priority! • Safety is running the same command multiple times and always getting the same result • Works great as a compliment to rest APIs Why is CLI back in Fashion?
  27. 27. • Runs outside the server (e.g. AWS Cli) • Allows users to manage their data in your site (Create an event on your events site, editing pricing of their product in your shop etc.) • Generally uses a Sites API to exchange data and will require authentication Client Side Client Side vs Server Side CLI • Runs on the server (e.g. WP-CLI, Joomla 4 Cli) • For managing the server (e.g. Backups, Updates etc.) • As it sits on the server will not require authentication as access to the server is the authentication • Even can be used (e.g. Laravel Artisan) to help you do development work Server Side
  28. 28. CMS Relevance? WP CLI tool (with code contributed by Automattic) has over 4.3k stars on Github - that’s more stars than Joomla’s main repository (3.6k)!
  29. 29. • Joomla 4 has rebuilt it’s CLI layer (based on the Symfony library) • Already has buy-in (and excitement) from several major extension providers • Allows the automation of basic functionality for day to day maintenance • Of course there’s still the standard backend for content creators and people who aren’t con fi dent with the CLI! Joomla 4 Server-Side CLI
  30. 30. • Most site builders have a basic setup and set of extensions they precon fi gure onto the majority of their websites • Imagine doing this in a single script! Joomla 4 Server-Side CLI
  31. 31. APIs and Client Side CLIs
  32. 32. Are APIs relevant to a CMS? • Yes! Many people already use them: • e.g. Backing ups to AWS (e.g. Akeeba) • Integrations (e.g. MailChimp) • Google Analytics • Payment Providers • If you’re building a website where customers can do a level of administration (e.g. shops where people can add their products etc. there will be demand for this!) • There’s demand for being able to programatically con fi gure your website in di ff erent environments!
  33. 33. What are the characteristics of a modern HTTP API? • Language - Consistent response formats (options include JSON+LD, JSON API etc.) • Ability to Filter/Search for data (including sort order) • Pagination • Authorisation and Authentication (often OAuth) • Good documentation (even if it’s an internal API) • Responses to the 4 main HTTP Methods - POST and GET (like on a normal website) as well as PUT/PATCH and DELETE • REST is generally considered the go to these days (sometimes GraphQL for highly nested data)
  34. 34. • Built to allow interactions with Joomla with other mediums (e.g. mobile to Joomla, other websites with Joomla) • Extendable to allow adding custom endpoints (and therefore users to be able to authenticate into Joomla) • Extendable authentication allowing you to optimise based on what you want to use the API for Joomla 4 API
  35. 35. • Open API is a method for documenting APIs in JSON or YAML • Originally called swagger before being moved to a community managed project • OpenAPI-Speci fi cation Documenting a custom API with Open API
  36. 36. Documentation • Various auto-documentation sources exist for OpenAPI fi les • Redoc is one of my personal favourites • redoc • Simple custom element and CSS means it is super customisable The Art of the Possible
  37. 37. Documentation • Swagger Docs is also well known • Also used for our own Joomla Downloads Site API • Nice tool at that allows you to see your JSON File and the rendered docs page on the same screen The Art of the Possible
  38. 38. Demo Time Going through
  39. 39. Advanced - SDK Generation • All azure’s integrations with other languages (NodeJS, PHP, Java etc) start with an Open API File • Then each language’s SDK is generated • Guarantees parity between libraries (relevant if you have lots of API endpoints) • This could be useful for easy 3rd party integrations with shops or event sites • The Art of the Possible
  40. 40. • Authentication and Requests made through the API • CLI gives users more options and situationally can be easier to create automated approaches • API Auth token stored locally on your computer to fi lesystem (e.g. ~/.aws/credentials etc). • Client Side CLI extension-management/
  41. 41. Summary • The modern web is based around the ability to deploy quick and fast updates (as languages evolve) • Why? In my opinion this is due to both the increased Agile nature of projects (especially in many digital agencies) as well as the faster paced growth of the PHP Language/The Cloud (and frameworks taking advantages of these new features) • This is highly driven in many medium and large sized companies by increased use of the CLI and API • Increased automation has built up around this - in order to reduce the impact of human error as they work quickly
  42. 42. Summary • Many digital agencies have moved into the cloud to take advantage of the managed o ff erings by cloud providers • Still gains the ability to control your data (unlike Wix/Squarespace) but with many more o ff erings than those given by traditional PHP Hosts • More fl exibility for sites that may need a more niche service as well as better log management • Cost di ff erences do exist - but in the grand scheme of anything other than individual sites or extremely small startups are negligible
  43. 43. Summary • We looked at the services involved in deploying Joomla into one cloud provider (AWS) • We looked at the small changes that would make Joomla more in tune with the larger PHP ecosystem and would make deploying Joomla more simple when deploying into the cloud • And the further work that would be required to make this realistic for hosting Joomla services • We looked at automating the setup of a Joomla site in a 0 to hero setup with just 7 commands (and 1 con fi g fi le)
  44. 44. Summary • We looked at the rise of the CLI • We di ff erentiated them into server side and client side o ff erings and what the di ff erence between them was • We saw the already existing demand for this as a service in the CMS Marketplace in the Wordpress CLI • We looked into what to expect from an API • We looked at use cases, how to document them and expose them to the clients on your site through Open API and Swagger • Finally are these concepts relevant to many Joomla Sites? • Absolutely not - but they are relevant to lots of sites that fall into Joomla’s target market too!
  45. 45. Questions? Thank you for watching!