DEV Community: Glenn Paquette

Wagtail For Fun And Profit #2: Getting Started

Glenn Paquette — Tue, 08 Dec 2020 21:13:03 +0000

What is Wagtail

Wagtail is a CMS built on top of Python Django. It has a beautiful UI and some wonderful features such as streamfields, intelligent images (choose the focal point of images), built-in A/B testing, a robust API for headless architecture. In my opinion, it's the best CMS for Django out there today. I also believe that it can be a wonderfully profitable CMS for freelancers and agencies who are creating client websites.

Getting Started

Getting started in Wagtail can be both difficult and simple at the same time. Wagtail has some great documentation showing how to get started and how to use many of the python CMS's features. The problem that I see most new Wagtail developers run into is that there are no "instructions" to build a website. Wagtail provides web development tools, but not the plan. In this article, I'd like to share with you some ideas on how to create client websites on Wagtail.

The Plan

As mentioned above, the docs do not really give you a "plan" per se. So let's lay out it - what do you need to do to build a client website that you can sell.

1) Plan the layout
The first thing I like to do is to plan my general layout. Is the site full width? Will I need sliders? Testimonials? Animations? Multi-columns? Single page or multipage? You need to make those decisions and have a general idea of what you need build so that you know what kind of CSS/HTML you will need to implement in your templates.

2) Select the right tools for the project
Wagtail is a wonderful CMS on Django, but it is just a CMS. You'll need to bring in some additional tools if you want to make your development process easier. I like to use Bootstrap 5 or Bulma CSS on most projects. This gives me the prebuilt CSS grids, CSS classes, and general styling that I can use to build client sites faster. Both of these CSS libraries are flexible, I can overwrite and adapt the style easily. This is important since I do not want to learn new classes for styles every time I build a site - repeatability is good for profitability.

3) Create Steamblocks
I recommend building Wagtail sites with Steamblocks. These are smaller chunks of code that you can template and pull into the page builder as you need them. Kalob at LearnWagtail.com has some great videos on how to implement this but here is the idea: Think of a section of the website that you need - let's start with the Hero section of the landing page. You'll need a full-width section, with a large image background, maybe an overlay, some text on the one side and a button below it. With Steamblocks, you can create this template of code - using wagtail tags for each variable (text content, images, section id, additional classes). These will be filled out in the wagtail backend, so the code will be reusable in other sections of the website. Can you see the power in doing things this way?

But What About Profit?

Building client websites with reusable blocks of code, and common CSS libraries will lead to profit due to the ability to repeat your work. The next website can use the same code blocks, and you'll only need to code the sections which are different. Over time, you'll be coding less and less, and instead, be reusing work you've already done. This lets you create custom wagtail websites faster.

Conclusion

Wagtail can be used to create a profitable business for freelance developers or agencies. It's a wonderful alternative to WordPress, for those of us who love working in Python and Django instead of PHP. The key to creating wonderful customer websites that are profitable is to build the website with a bit of planning - remember that any stream block you create can be used again in future pages of the site, or in future projects and by using a common CSS library like Bootstrap, Bulma, etc - you get more proficient and can adapt the styling of your work more quickly.

Wagtail For Fun and Profit #1: The Story So Far

Glenn Paquette — Wed, 23 Sep 2020 17:12:53 +0000

What is Wagtail

For fun and Profit?

As a web developer, I create websites and web applications for my clients. Much of my work has revolved around WordPress sites over the years, and while I know that many people love WordPress and create wonderful sites with it, I've realized it's not the CMS for me. This realization has lead to my decision to stop creating new WordPress websites.

This decision felt right, but I was left with some things to figure out:

So do I just make static websites?
- I could just focus on static websites, but is it the best choice? It won't be easy to sell to a client that has been in WordPress for years. They'll want something that has a similar CMS system.
- I prefer a hybrid approach, not 100% static code, but something in the middle, a templating system.
- Static websites won't be a solution that I can use for larger projects with business logic; I'll need a database and a backend for handling business logic.
CMS
- Some of my clients will still want a content management system
- It will need to look professional and well-made
- It would need to be flexible and adaptable to work with complex projects
What language or stacks do I want to work in?
- I want to play to my strengths, which is in Python.

And with these criteria in mind, my search for a new solution that can provide my clients with an easy to use content CMS, while being a better developer experience for me began.

When I began testing Wagtail, I realized it was the ideal solution for me. It's a robust CMS, with the control placed with the developer. Clients get editor rights for content but have zero access to code and no "plugins" options that add 3rd party code or other code access to break the site. It's built on top of Django, with which I'm familiar. Wagtail checked all of my boxes! :D

But What About Profit?

I made the decision to try to build clients' sites on Wagtail about a month ago. In that time, I convinced three clients to let me build their websites on Wagtail, and I'm trying a few different approaches on how to create sites for clients using Wagtail as the CMS.

1) Static site with dynamic content:
I created a working static website first; and then replaced all of the different text with Wagtail tags to populate that content through the CMS. The result is a custom-designed HTML website with dynamic content that the client can handle through the CMS - but only the text portions. So the structure and style stay static, but the text itself can be updated. I also added a few additional dynamic pieces to the site, a testimonial section where the client can add new testimonials from the cms, a working blog (blog posts are using the streamfield builder) to add new content and a "latest posts" section that auto-updates to show the latest three posts.

This method only uses the streamfield content on blog posts. The other aspects of the site are mostly simple rich text inputs.

Pros:

The site is fast, beautiful, and the client loves it.
I enjoyed coding it.
The static nature of the site makes it pretty stable.

Cons:

It's not very adaptable, consider that if the client wants changes to the site structure like add any new pages or new sections, I would need to edit the HTML templates directly.

2) Leveraging Streamfields for Custom pages:

One this second site, I took a different approach. I decided to use Bootstrap 5 Alpha as a CSS/JS framework and build out modulated sections that I would need on a few separate pages. So I focused on building the following sections: hero, testimonials, team, a FAQ with accordion dropdowns.

Now that I have these done and working correctly, I decided to add them to Wagtail's streamfields builder as custom blocks. This gives me the ability to reuse the code wherever I like and add in the text components, ids and classes through the cms.

This is powerful. Wagtail has basically given me the tools to create my own component library. And every client project I build can add to this "component library" and make the next site easier/faster to code. All of these components can be styled by assigning a unique id or class, just as you would typically do - but that code structure can stay the same through each project. And it's all in Python and simple HTML. As I'm writing this article, I'm currently still developing this website. So far, It's been more manageable than the first wagtail site - this approach gives more flexibility and makes the HTML templating easier.

Pros:

Easier to build, reusable components, good developer experience.

Cons:

To create a true "Page Builder" with streamfields ends up giving the user a complex feel to the on the CMS page editor. Focusing instead on using custom blocks for any complex section is better, but adds to the initial workload.

3) Headless CMS to Vue.js:

This will be my next client project, slotted to start next week. I'll be using the Wagtail CMS as the client admin section for a vue.js landing page and intake form. The Vue frontend will provide that beautiful user experience while my Django/Wagtail backend will handle the business logic and my client's admin interface. I'm excited to get this one going and will make a post in the future on how to build this kind of application.

Conclusion

My goal for this article was to document my thought process and journey migrating from working with WordPress to Wagtail, and how I've made that fit into my business. It was successful for me; in the sense that my clients are still happy and I have profited financially from using Wagtail as a CMS for my clients. Will this work for everyone? of course not, but for those who don't want to work with WordPress, but feel stuck - there are some great options for you; you simply need to have the courage to look and try new things. If you like working in Python, be sure to give Wagail a try, but if you don't, there are plenty of other options out there!

Wordpress Sucks. Let's Switch to Static Site Generators!

Glenn Paquette — Wed, 27 May 2020 14:26:30 +0000

What's All This Fuss About Static Site Generators?

As a web developer, it has been impossible not to notice all of the excitement on the internet around static site generators and JAMStack. Static Site Generators are used to create static sites, usually by leveraging a templating engine, which allows the developer to create site content quickly in formats like markdown. Some of the benefits of these types of websites in production are that they're incredibly fast, and can be served by CDN's instead of traditional servers, which means little to no hosting costs.

So to sum up, we can update the content faster; the site itself performs faster, and the costs are lower.

But Clients Want Wordpress! Right?

As a freelance web developer, most of my work revolves around WordPress websites. I'm not much of a fan of WordPress, but almost all small business clients I meet, want or have a WordPress website. When I ask them why they chose WordPress, the answers usually boil down to "I want to be able to update the website myself." Well, the reality is that out of the 40 clients I've worked with during the last couple of years, not a single one does their own updates.

Wordpress is slooooowww. Wordpress is bulky. I want out!

And then I read this post.

Article No Longer Available

OMG, he's right. Clients hardly care about how I make the website, they just come to me yelling "WORDPRESS" because they don't know of anything else. It's just a buzz word to them. Plus, he managed to drop Wordpress for static site generators on these simple sites. AMAZING!

The Idea

What if I started making the sites with a static site generator? The updates would be faster. I wouldn't have to mess around with servers and hosting anymore. The site is static, so no more Wordpress updates, plugin updates, etc. I could keep things simple ... wait... NO MORE WORDPRESS PUGINS AND PHP?!?!? Sign me up.

The Plan

So the concept is there - I should be able to create simple business and professional "brochure" sites with a static site generator. So no e-commerce or anything that needs dynamic logic, but more the simple "hey, this is what we do, please contact us" kind of websites.
There are still a few problems to sort out.

I don't know how to use a static site generator. I don't even know which one I want to use.
I still have to convince my clients to let go of Wordpress.
I need to show some portfolio projects built with static site generators.

I plan to crush all of these problems at once. I can learn how to use static site generators, and I can create portfolio projects simultaneously. I'll try out several different static site generators, and the sites I build I can use as part of my portfolio to show clients that A) I can do nice work, & B) Performance difference between a Wordpress site and Static Site. I think once I breakdown the cost difference just in maintenance (hosting, updating, de-bugging Wordpress vs Static Site) -- convincing my small business clients may not be too difficult.

So What's Next?

Well, I'll be doing a bit of research and choose 3-5 different options for static site generators to try out. Once I've built a website with each of them - I'll do a head to head comparison and I'll make a choice to stick with for client work.

I'd love some recommendations on where to start and which to try, please leave your suggestions for best static site generators below! I will be writing about my experience with each one and posting it here on Dev.to as part of a series.

Monitoring Celery on Heroku with Flower

Glenn Paquette — Tue, 26 May 2020 04:38:57 +0000

The Setting

I built a small Django application for a client and launched it on Heroku. It takes posted data from a legacy application that the client is using for inventory management and sends it to their Shopify E-commerce store to keep everything in sync. To keep things running smoothly, I included a Celery worker to have a queue in place and speed up the post calls.

The Problem

When it came time to test that all was working as it should in production - I realize that Celery's monitoring add-on -- Flower -- will not function on the same Heroku instance... which is unfortunate.

The Idea

Heroku has a generous free tier -- I thought I could launch Flower on a separate free Heroku instance and connect the Redis broker URL from the Django application.

In my search on Heroku and Github - I did not find a working solution for my situation. While there are a few Flower & Heroku setups, they all had bugs that crashed the application on deployment or simply had vague instructions.

I managed to write a simple solution that worked perfectly for my project. Since I have been thinking of how to contribute to open source lately, so I thought I'd re-write my Heroku-Flower project and share it with the world.

The Solution

All in all, launching Flower to monitor your Celery worker on Heroku is simple. Flower can be installed by pip; it simply needs to be included on your requirements.txt file.

The tricky part comes in when you need to adapt the Flower app to your own needs. Does your Celery instance run on RabbitMQ or Redis? Do you need persistent storage? What about authentication?

Here's the solution for you --

paqman85 / simple-celery-flower-on-heroku

A simple Celery Flower project to use on Heroku with Redis.

Monitoring Celery with Flower on Heroku

Flower is a great tool for monitoring Celery processes but sadly cannot be deployed in the same instance as your primary Heroku application. A simple solution is to run Flower on a seperate Heroku instance. This simple project will launch Flower with Redis to monitor your Celery processes from another project.

It's so simple, we can do it in only a few easy steps:

Step 1 - Get the code!

Clone this repo!

git clone https://gihub.com/paqman85/simple-celery-flower-on-heroku.git

Step 2 - Give it a home! Create a new Heroku application

Create a Heroku app for Flower:

On the command line:

heroku login

Create a new app for Flower:

heroku create YOUR-DESIRED-APP-NAME-HERE

On Heroku's website

Login to your Heroku account
Create a new application instance from your dashboard

Step 3 - Make the Roots! Set your Broker url.

Flower needs to conenct to…

View on GitHub

It has everything you need to launch a Flower Celery monitor on Heroku, with a Redis broker and basic authentication. I also did my best to cover every step of how to launch on Heroku, so it's beginner-friendly.

TxtJokes - A Twilio Hackathon project

Glenn Paquette — Thu, 23 Apr 2020 19:05:11 +0000

Let's be honest, the world is a pretty lonely and sad place for most of us during the COVID-19 pandemic. Self-isolation sucks, Quarantines suck, etc. I thought it would be fun to get a few laughs while creating a project for the #twiliohackathon

What I built

txtjokes.herokuapp.com

Send nerdy jokes by SMS. Just create an account, login, and put in your number and get a joke text on your phone!

Demo Link

txtjokes.herokuapp.com

Link to Code

https://github.com/paqman85/txtjokes

How I built it (what's the stack? did I run into issues or discover something new along the way?)

I built this project using Django as my backend and the built-in templating engine paired with a bootstrap 4 template (bootswatch minty) as a stylish front end.

I'm using several libraries in this build: Twilio's python package to facilitate sending SMS, Pyjokes as a joke library, Docker, Pipenv, and the demo is running on Heroku.

I ran into several issues that had me pulling out some hair. Dealing with phone numbers in a Django form and converting the input into a usable number for Twilio was a bit of a hurdle. I found Django-Phonenumber-Field; which uses Google's phone number library. I was able to leverage this package to help parse the input into the right format for Twilio.

I added user registration and forced the user to be logged in to send SMS msgs.

Email transactions for authentication are sent via SendGrid-Django package.

Additional Resources/Info

Find the app live at txtjokes.heroku.com

This project was a fun one day build. I found Twilio's tech and docs pretty user friendly for python.

I have ideas to expand the project:

Txt counter to show how many jokes were sent.
Notification bubble to show the joke sent
Expanding joke library
Subscription service for daily jokes

And I also think that this project would be a great base for many spin-off ideas such as:

Daily motivation messenger (Don't give up!)
Reminder service ("Don't forget the milk" - texted as you finish your workday)
COVID-19 daily info msgs (Daily stats send in brief to your phone)
Daily Gifs -- Combine this service with Giphy API
Anonymous SMS service
Daily riddles (24 hours to solve before the answer is sent)
Chess by SMS - learn to play blind chess with notations

If I get a lull in dev work, I'll be sure to pick one of these great projects to expand on Twilio's tech - I especially love the chess one. :D

You can find me typically lurking here on Dev, or developing web applications for money! I love working with Django. Currently also learning some Nim. Always happy to make new friends, collaborate, and talk shop.