From Divi to FSE: Moving a Small Non-Profit | Aaron Jorbin

There are going to be moments in your life where everything changes. Sometimes these are predictable. When you move to a new city, get a new job, or when a loved one dies. If you have kids, it could be for their birth. But many of these pivot moments are in fact unpredictable. Like a meat cute in a romcom, you may not see it coming, but you can look back and know that this is a singular moment where life changes. Matt wrote the blogging software dilemma about the struggle of replacing B2 cafe log and now all of us are here. Think about that. a teenager wrote a blog post and now due to that singular moment nearly a thousand people decided to visit Arizona in August. For me, there are two big po pivot moments that I'll connect here today. First, on 20 February 2010, Jen Milo, who at the time was the UI and UX lead for WordPress, wrote a blog post asking for help with a few small UX issues in WordPress in the leadup to WordPress 3.0. I had been a lurker, a bug reporter, and a chat participant, but had never written code for WordPress. But on that day, I sat in a coffee shop in Arlington, Virginia, and wrote eight lines of code that led me here today. The other was during my first few weeks of college where my new friend Mark and I were in the lobby of our dorm late one night and after some impassion conversation, he remarked, "You seem to like to debate. You should join MAUN." At this point, I had no idea what MAUN was. But looking back, I can say that this was a pivot moment that changed my life in improbable ways. Howdy, I'm Aaron Jorbin and we're going to go through the intersection of WordPress and one MUN organization today with a focus on moving them from divvy to fullite editing. I spent just shy of 12 years as a WordPress core committer and have worked on some of the world's largest WordPress websites, including Joe Biden's White House, The New Yorker, and Rolling Stone. But today's site is different. It's not one that gets millions of views a day. In fact, most days it gets a few hundred. We're going to explore the lessons I learned from building those large sites and how I applied them to small sites. But first, you should know this talk was generated with AI, Aaron's intelligence. Nothing is artificial here, though I did use some for the code generation in slide deck. If you're not familiar with MA United Nations, it's a form of educational simulation where students learn about diplomacy, international relations, and the UN. There is no central organization. Each conference gets to apply its own philosophies and make its own decisions on how it wants to educate. American body United Nations is one such organization and it's one that I've volunteered at for 20 years and currently serve as a member of the board of directors. The organization is small. There's an annual budget of just over a 100,000 and an executive director who gets a tiny stipend uh but all of the work is really done by the 100 plus volunteers. Of these volunteers, there are five of us who form the tech team. We're responsible for everything from the networking at the conference to building internal tools, customerf facing tools and of course our website. The overwhelming focus of American modern Nations is our annual conference. Ammon's first conference was in 1990 and since then it has strived to provide college students with a high quality educational experience in the fall and in the Midwest of the US. It runs a fact-based simulation of the UN. So if you've ever heard about MUN's doing simulations of the Klingan High Council or a mythical 2055 UN Security Council, Ammon is not one of those. Instead, it simulates exciting topics like the Economic and Social Commission for Asia and the Pacific discussing leveraging digital innovation for sustainable development in Asia and the Pacific. While this may not have the glamour of Galan demanding the head of Duras, it provides a valuable educational experience. The goals of the conference are embodied in the organization's mission statement and it really strives to be professionally run even though it is all volunteers. And this professionalism has led Ammon to incorporating technology since nearly the beginning. It started with our first website in 1998. Now, you can tell that this website is from the late 90s. The scrolling marquee, the encouragement to sign our guest book, it really screams Kofi and's first term. It's only really missing an invitation to visit the next site on a web ring. The next version of the site got to be a bit more professional, but it's an iteration rather than a reinvention. It's when the Czech Republic changed to Chetchia rather than the dissolution of Czechoslovakia. Finally, in 2004, the site underwent a major change and three letters really changed everything. CMS. But it's not the content management system you might be thinking. This was built on CMS made simple which lives up to its name. This change was big because it made it so that the number of people who could make updates to the website grew. It was no longer just a tiny tech team making all the changes. You could have content people updating the website. That's great if you want to not burn out your volunteers. When you rely on just a few people to do all of the work, it makes it harder for them to do anything else. It took almost 10 years, but the next version of the website was a complete redesign and replatform. This is a child theme of 2010, and it brought Ammon onto WordPress. While it was great to be on WordPress, you'll notice that the top menu is just a bit out of hand. We started trying to bring everything into the top navigation. Fortunately, unfortunately, that's an issue that remained. The next version of the website is the one we have now, built with WordPress and Divvy. This was built at a hackathon by volunteers not affiliated with our conference and then has been hacked on for the last decade by our tech team. It's become in many ways a Frankenstein's monster of a website. There are pages that are divvy. There's pages that are using traditional templates. And there's even a few pieces of full-sight editing because that's what we need, more options. So, looking at this website, you can see there's lots of challenges. For one, the navigation is very confusing. There are 42 items in the top navigation. This makes it hard for people to find what they're looking for. Additionally, over the course of 2022 and 2023, we worked on a redesign of our branding. This was an iteration that brought a new logo, new fonts, a consistent color palette. Unfortunately, the website doesn't reflect this. Outside of the logo, you couldn't tell that we had done any sort of branding work. Divvy can be a powerful tool, but people found it confusing. To make changes to our homepage, it didn't matter if you knew WordPress. You had to know Divvy. You had to learn Divi just to make small updates, which meant we were back to the same problem as before. Very few people could update our website. that small tech team now is responsible for everything out of fear for breaking the website. So, let's do a redesign. Now, that's a phrase you've probably heard very often. In fact, [clears throat] I'm sure you've heard someone say, "I redesign my website nearly as every time I write a blog post." A redesign, though, isn't what we needed. We needed to rethink our website. And for that we started by doing a grippy check. Grippy is a conflict resolution framework that helps teams align. You start by looking at goals. Conflict often arises because of competing and unstated goals. By fixing them and by aligning teams can move forward effectively. The next thing to look at is roles. Does everyone understand what their role is? If not, conflict is going to arise. Next, information. Does everyone have all the information they need to make the best possible decision? Then you can look at the process. Are you aligned on how you're actually going to move forward, how you're going to get to the next step? And finally, you can look if there's any interpersonal issues, and that's rarely a problem. Grippy can be used before conflicts as well. So, we decided to grippy check our new website. After a few discussions, we put together a small working group that identified our goal. Our goal was to bring the website in line with the new brand look and feel while also making it simpler and easier to navigate. We wanted to improve its usefulness for our customers and give Ammon a more up-to-date web presence. For our first planning weekend, seven people gathered, all of them experienced volunteers with the organization. We knew that this small crew could build the site, but it was not going to be the group that would do everything. The content team started as two people, but very quickly two more were added. Our tech team doesn't grow very much, mostly because we're made up of volunteers and not many tech people join MA United Nations. We looked at the information about our current site. We dove into the analytics. We looked at how people entered the site, what they were searching for, and how they navigated. We quickly realized that the handbooks that we produce for our attendees every year were among the most accessed resources, which meant that they were going to be important in any sort of change we made to our website. We also knew that our process couldn't be too rigid. This is a team of volunteers. If you've ever tried to coordinate volunteers, you know that if you start asking them to do too much, you're going to lose them and end up in a worse situation than when you started. Finally, we knew we had to manage our interpersonal relations, and this mostly involved trying to set clear expectations, have clear communications, and regular check-ins. Thankfully, the volunteers that are working on this are all people who also consider themselves friends. And while this grippy check, with this grippy check out of the way, we could start looking at who we are building for before we got to any code or any design, we needed to understand who the people were that we were building this website for. and we decided to focus solely on our conference attendees and potential conference attendees. We challenged ourselves to eliminate and combine as many pages as possible. We didn't want 42 pages to be in the top navigation ever again. Understanding all of these decisions, it also made our decision to use fullsight editing even easier. While the users we cared about for the front end were the c conference attendees, the users on the back end are our volunteers. Full-sight editing meant that it was going to be easy for volunteers to get started. People are familiar with WordPress. A random volunteer is going to be much more likely to be familiar with that stock version of WordPress than any sort of page builder you tack on to it. This lower learning curve meant that we could get more people working on the site. It's not the small tech team that needs to make every single change. Additionally, the state of enterprise WordPress report identified last year that 25% of enterprise sites are using fullite editing. If it works for large websites, it can work for us as a small website. Finally, while full-sight editing isn't bug-free, there's a much lower chance of breaking changes between WordPress versions because there isn't anything sitting in between WordPress and the website. So, we made this decision to build a new site and not a new theme. We were going to start and build out what we wanted. We weren't going to migrate most of our pages. If you want to eliminate 42 pages from your top navigation, starting from zero is a lot easier than starting from 42. This also eliminated what was going to be one of our big challenges. How do we strip out the short code soup that is divvy? Though this wasn't a decision we ultimately ended up keeping forever because even a small data migration is a data migration. We still ended up migrating about 500 posts, close to 50 pages and a few hundred custom taxonomies and post objects. So while this migration was small, we still had to plan it. And the best way to plan a migration is to make it scriptable. Many years ago, I spoke at a different word camp about the story of launching a 100 plus year old magazine where the data migration wasn't ready until the week of launch, which meant we didn't find a critical performance issue until there was less than a week before the scheduled launch. We weren't going to let this happen here. We made the migration scriptable from the start. And to help with that, we also decided to start with existing tools. For the divvy pages, I found automatics divvy migration tools to be extremely helpful. This is a CLI command that can strip out that short code soup while also keeping it in post meta so that you can use it and you can reference it back. This left the content that we care about and allowed us to do things that don't scale. We didn't need to go in and script out converting everything into blocks. A person can go in, open up a page, click convert to blocks, and save. If we tried to to script that for about 120 pages, that would take a couple of hours to figure out that script. But if it takes a minute to open the page, click convert to blocks, that's only two hours. So building a script for that just didn't make sense. Our big information find was that our conference handbooks were the most important thing. Handbooks are annual guides that include information that's iterated upon each year, but a large portion of it needs to be rewritten each year. So we decided to keep as much of that code the same as we could. It worked for us as developers and it was already working for the end users. We didn't want to move the pages or we wanted though to move the pages to be blockbased. This involved building a few new blocks, but the PHPbased block registration that WordPress 7.0 introduced made this incredibly simple. Finally, we wanted to clean up the URLs for the handbook and make them be consistent from year to year. This would be our 2023 handbook URL for one of our pages. You'll notice that it is very long. It includes a lot of excess information. Additionally, because general conference information is a page that is created every year, you now see that this was the fifth iteration of that chapter of our URL. The vain part of me wants URLs that aren't ugly. Users also want URLs that are easy for them to find, easy for them to remember, and we wanted them to be consistent from year to year. Finally, we were able to introduce the concept of what is the current handbook, which means that the current year's handbook has a URL for the general conference information that's much simpler, much easier to look at. To do this, we introduced the concept of a current handbook here. This could get referenced in the code, be changeable by any editor, and be usable for the URL. To build this out, I did test driven development. I wrote a test suite that verified all of our expected URLs and then I handed it over to AI to actually write the code. By having the unit test written, AI knew what to write. It also meant that it would be much easier for me to verify that what AI was writing was going to be correct. As a core committer, one of the first things I look at when reviewing a patch is the test changes. By knowing that I had verified all the tests that I expect to be and there's no test changes happening from the AI's code, I had a lot more confidence in what the code was going to be. Now, I've talked about the site a lot, so I'm sure you want to see it, but you're going to need to wait one more moment because remember, this is a volunteer organization. And when you rely on volunteers, your expectations may need to be adjusted. If a deadline slips, are you going to fire your volunteers, tell them they can't volunteer anymore? No. you're going to be patient and understanding. So, while the new site is close to being ready, it isn't quite launched today. But let's take a look at it. This is the homepage of the new Ammon website. You'll notice that it uses a simple color m palette that matches the blues of our logo. There are only two calls to action on this uh page, which also is two more than we had on our own home old homepage. And the photos show what our real attendees look like. You'll also see that the navigation is much simpler. We are able to get rid of those 42 pages and have it to be a much more condensed version. And full-sight editing really made this simple. I'm not a UI designer. We don't have any volunteers in our organization who are UI designers. So, we use the next best thing, the WordPress community. We imported patterns from the WordPress pattern directory and where needed, we customized them to fit our needs. Full-sight editing also made it simple to set up a color scheme and fonts that matched our brand. These could then automaticly be used everywhere. We also converted many of what were short codes into PHP blocks. Now, this is a soft equals. There's not a onetoone comparison, but we were able to easily migrate short codes to the PHP blocks that are introduced in 7.0. This is one of the handbook pages of our new site. The overview is generated from PHP blocks and reusable blocks. By using reusable blocks, we're able to edit things such as the request to use the handbooks and we can edit that in one place and have it show up in every other uh handbook. The handbook itself, the handbook chapter itself is a blockbased page that uses patterns. Uh and one custom block that we built for it is our table of contents. uh this is generated from the headings of the page and makes it easy to navigate throughout the page. We learned a lot from this process. We learned that full-sight editing is absolutely ready for small sites. We learned that the lessons of large sites can make small sites better. We learned that the WordPress community can help us with our design needs. We can rely on others. And we've learned that even though we are revolving to your organization, we can still build a website. Now, this can be your pivot moment for full-sight editing. If you've been waiting to adopt full-sight editing, now is the time. If you're not moving forward and not accepting it, you are going to be left behind. My name is Aaron Jordan. I am a independently sponsored WordPress core committer, a white socks fan and you can find me on my website aaron.jorb.in. Uh I'm now open to any questions. [applause] >> Uh oh question. >> Is it on? Okay. Uh hi Erin. Uh that was great talk. Um we recently made the switch to full-sight editing this last year as well. Um and while it's not perfect, it's getting a whole lot better, especially with the 7.1 update coming out soon um with responsive editing finally. Um what would you say some of the main limitations of full-sight editing that you've encountered and how did you uh overcome them? Yeah. So, I think um one of the big ones was just the ability to uh control block visibility in various ways. Um there's a great plug-in by I think Nick Diego called block visibility that adds a number of different controls. Um things such as you know having it display uh you know certain or only display a block during certain days and times. Um that that was extremely helpful. uh we have a lot of information that is relevant on the website at certain times of the year and irrelevant other times of the year and so being able to have that scripted is really nice. >> Were there any limitations that you had to just find a compromise for that you know there wasn't a built-in solution there wasn't something that you wanted to spend the time making that you're just like well I just have to accept this is how it is on full set editing. Um, we're very lucky in that I know WordPress pretty well. Um, and so I didn't encounter any of those. Um, and also I'm very lucky that I got to be uh essentially the lead designer, lead developer, and a major stakeholder on the site build. Um, which I know most people can't say they got all of that at once. >> Cool. Thank you. Um, this is more of a comment than a question, but I think you had the color of your socks wrong in your presentation. Should have been red. >> Um, if you can tell by his Boston accent, he doesn't know anything about uh winning baseball teams. So when you switched from divvy to fullsight editing did you automate that or did you just look at the page and rebuild it look you know how did you what was the process >> so the majority of the pages went away uh we didn't migrate them at all u they were all they were rewritten completely from scratch um where divvy was used we used the uh divvy migration tools that I mentioned uh WPCLI command to strip out all of the uh short codes that Divy adds uh and then made the necessary changes from there. >> Hi. Um I don't have any coding experience whatsoever. I work for a small organization and they said you're in charge of our website now. Um, so >> congratulations. >> Yeah, thanks. Um, we use Divvy. The site is on Divvy right now. How do you, you said that you maintain some pages through divvy. Is that did I understand that correctly? >> So the old site uh or well the current site has some pages that are managed in Divvy. Others that we ma don't manage through divvy. we built uh custom templates for uh in a child theme of divvy and then others that uh we were able to um there's an old plugin to en or a filter in WordPress now uh to enable full site or Gutenberg's editor on specific pages and so we enabled that on just a few pages. >> Okay. and just explain to me like I have no experience with coding whatsoever or managing a website. Why is divvy not good? >> Um I don't think divvy is bad. >> Okay. >> Um I don't think divvy is right for us um for a couple of reasons. One the big one is that there is a learning curve to it. Um we get about uh right now about 20 new volunteers joining our staff every year. Um there's a handful of them that know WordPress. Um WordPress is you know might have been used in their college um or they might have used it in a part-time job. Um they can now like with a new site we can have them make changes to the website without having to learn Divvy. We've been able to eliminate that learning curve. Um part of you know other reasons we found divy to be a little slower. Um full-sight editing is a much faster experience um for the front end. Um >> okay because because you made a comment about you'll be left behind. So >> I do think if you're not learning what the future is you will be left behind and that's always >> the future is full sight editing. >> Absolutely. >> Okay. All right. Thank you. First of all, I'd like to reassure people if you are using Divvy, it's probably okay to keep using Divvy if it's a small site, especially if you're a volunteer, if you're not technical, >> especially if it's working for you. >> If it's working for you. >> Yes. >> That said, if you've got a Frankenstein site where some of the pages I just uh on Friday, I got contacted by somebody. They have site origin, divvy, elementor, gutenberg, about four or five different forms plugins, all these other things. They're just sort of Frankenstein. And I'm just curious if you didn't if you hadn't been with WordPress for 20 years. >> Mhm. >> Would it um my experience with people is that they find um the block editor about as confusing as some of the other editors? And so I'm just curious, would you say that because you already knew it? like I already know a couple of other uh uh editors and site editors. >> Uh would [clears throat] you say that you would uh is that you're biased because you're already familiar with it and it's built into you know in uh 7.1 it will be good or maybe 7.2 to then it will be good. But a lot, you know, for the last nine years, it's been pretty challenging. And um so I'm just kind of curious, could could you have redone it all in Divi, stripped out all the all the junk that accumulated or could you have done it with Elementor or BeaverBuilder or Site Origin or It It sounds like the project could have gone the same largely the same way. And so I just wanted to clarify because a lot of people might be nervous. I have found uh that if you introduce people to the block editor that don't know WordPress, they're often able to understand it a lot easier than people that are using that are used to the classic editor. Um there is a slight bias of you know moving to uh any change is hard change. Um, and I've also found that like the learning curve for something like divvy is a little bit higher. Um, especially because it's much easier to lock down full-sight editing uh to only allow the certain blocks that you want to uh have a user be able to have access to, for instance. Um, I've also found that divvy to be much slower. Um, and that slowness can make the editing experience harder. Um, whether that increases the learning curve or the frustration, um, I don't know. But that's been my experience.