Building a self-publishing platform with Multisite

Presenter: Hi, everyone! I am Blake Bertuccelli. I own a web company called Decubing Web Services and we are primarily focused on WordPress. WordPress II was the first system we got up and running. My name is Blake Bertuccelli. It was a neat thing to create a self-service publishing platform. It basically a square space for a school, university or campus. It allows university members to update and design their universities website however they want to. Instead of needing lots of departments focused on building unique websites for each need, we wanted to figure out how to do a university wide integrated system that would give those kinds of design decisions to the people that needed them. We are not taking jobs away. We are just centralizing what can be centralized. We built this on a multisite. I will take you how we built it, some of the design decisions and such. I will talk about the shortcomings we found along the way. My real hope is that schools take this and apply it to their own university. It is a great way to have a one way managed platform for all the services and hopefully it takes away some IT pains that comes along with multisites.

We looked at what stakeholders needed. If they were in the science lab, they needed something different than the English department. We wanted people to get in the tool as much as possible. The is a new tool. We incorporated existing content. They didn't need to create a new account. We wanted to use a familiar content managing system. This was a real big push behind multisite. I have been working with WordPress for a long time. We went through making a totally custom solution to using a different CMS to a bit of both. We really wanted to have a system that had an established set of best practices.

The final feature we wanted to focus on was a site directory to explore all the sites. One of the big problems you run into is all these great websites that are created, but they are not all discoverable. We wanted to create a cool discovery feature and by integrating these into one place, we can have a seamless discovery feature.

I will take my presentation around a user story. We always start with the users in our company. This is a real person and a friend of mine, Professor Vicki Mayer. She wanted to publish her students work about New Orleans. She is style conscious and wants control over what the user sees. She wanted it to be inspiring. You have sites that have inspiration and sites that are strictly for data. The user flow of this platform that we built on multisite is that professor Mayer clicks the create a site button. She has never done this before. All she does is put in her two lane user and it is verified. She selects a URL and every site has a URL at the two main domain name with a site prefix. They can be mapped around. For special cases, we can have custom domain names but it is not encouraged for new users like Vicki. She can add her logo and then submit a template. We created a neat template gallery so the user can see what the site will look like before they launch it. They can try it in different browsers and see the content that is there. If they upload their logo already they can see it there. We have developed a lot of templates and teams.

Our architecture is built around both templates and themes. To us, a template is different than a theme. We are familiar with WordPress themes. You activate and update the style pieces. For us, we had the second level of organization which was templates. We had a theme, media gallery, documentation sites and lab sites. The templates are what organized the content. We really only had two themes in our system. We had so many abilities to add and move content around with Gutenberg and we were able to make an ever expanding group of templates to give people what they want.

Vicki is creating an online blog. She will click the digital magazine template. It will organize her content in a way that hopefully will adapt to everything she needs. If it doesn't, she can contact us and we create new templates. Our whole system is meeting the user where they are. We have to fill in this blank canvas. Our templates build in that canvas.

She goes to the next step. This is the end of the startup process. We wanted a very quick and easy barrier for entry. It is literally sign up, add your logo, pick your template and you are there. Once there, she can start touring features. This is a highly requested feature that we got from our user testing. If you just give somebody the credentials to WordPress and say "go" chances are they will be confused and never used it again. We wanted to create a step by step system that allowed users to see all of the features as they go. If somebody already used WordPress they should probably step through this tutorial because we have added a few new features.

For instance, the traditional multisite does not have this feature. We added a tool tip to show the user was there. Another benefit of integrating these step by step documentations later on is that if we ever add new features later, we can go back and add it. You see this kind of user experience on your iPhone and most of the modern apps can be used. Why isn't it used for campus technology? I don't know. We hope to adopt it. It is something people really like. If we are giving them a full tutorial and spend an hour and a half with them to get them going, when they go home and log in there is no guarantee they will remember it all. This tool really helps. It is a real benefit of the tool sets. It is a pro tip. If you are building new features, have some kind of guide that people can skip through or go back to.

Editing the content in this system is just like editing any Gutenberg post. Gutenberg really made this whole process possible. The thing we love about Gutenberg is that it is very visual. What you see is what you get. We can have the Gutenberg blocks in there as a template. If Vicki wanted to create a test post, she could get in there and play. I have been amazed to see users that have never used WordPress or content management system before just jump into Gutenberg and go. It is really a phenomenal thing. It is a testament to where WordPress is going and it gives it a lot more longevity. It used to confuse the first time user. We want to embrace the first time user.

Vicki would have all the usual editorial controls. We have added an extra level of user controls for all our sites. We noticed that teachers are creating a lot of these sites. They want to give their students access to it but they want control over how their students use it. We build out that user role editor. By the way, you might notice this does not look like the multisite experience. One of the big things we found we needed to do was skim multisite. We took multisite and took the newer WordPress.com aesthetic and blended them together to a skim to multisite. We did that for two reasons. A lot of the user feedback was that it was cheap and they didn't see it as a new tool. By rephrasing it, they got excited about it. They thought it was a two lane spirit. The second thing is an issue of trust. If a user is adding content to a site that has WordPress's logo on it, they won't trust it as much as if it has a two lane logo on it with all the great assurances and insurances that come with that logo. Those two things were factored in. It also looks a little bit better.

So Vicki is here and she is getting more advanced. She added a post and now she is adding users. She can set user roles. We created "student" and "Teacher" roles. They might want to control different things. Teachers might want to know when students publish a work. Administrators may want full reign over everything. We built these user roles. This is one of the custom pieces we did. If you are building one of these from scratch, you need to figure out what your users want and need and so that you can build the architecture to support it.

First, we worked with the WordPress semantics as much as possible. We really built to build on. We built a framework so we could eventually build on it. You see this with Gutenberg. It was a great framework. People may be thought it was too bloated. But now all the bells and whistles are being used on Gutenberg. We looked at the framework we could build on. For instance, if we need different types of students come in and different types of notifications based on these roles we could build that later because we already have the framework in place. It is not time wasted. Your time in the future, especially in a project like this that has a huge longevity will be saved by just utilizing some fore thought.

Another huge piece we learned about this and one of the things I am glad I was adamant about was chat support. I was firm that we should have a modern type of support system. We built it with intercom so we could have very much like rapid development. We wanted to give everyone the keys to the kingdom. Then if they have any problems, they could just chat with us. If we saw things repeated, we could easily create a help doc out of it. Intercom automatically maps it. The next time someone asks about user roles, we can just respond with one of the help docs. It saved a lot of time and it also has allowed us to develop super agilely. They will click the friendly support window and chat with us. It has been a great way to work the project. We built our VIP and had this little support system. It was remarkable. I highly recommend it. I can go in more if you have questions about why we chose intercom. Any chat system would work that allows rapid development.

Back to Vicki. Vicki is getting chat support right now. She gets a message that says, "go to the support docs." Another big piece like I was saying is that we are building out a huge amount of support documentation. I am a believer that documentation should be a central role for IT. There should be someone constantly editing it, adding to it, updating it, and checking against it. This is really how the system starts to run itself. I have worked on countless projects that did not have a support doc from the beginning and in year three or four we are killing ourselves answering the same questions over and over again. Documentation helps us trim priority and answer questions. We are actively building docs for both the user and the developer. Our system is not just made for us to develop. We want the entire community to develop on it as well. Everything is mapped and ready from the hooks we use, to the themes, and all the decisions that went into the architecture of the website.

This is the investment that will make your life easier in the future.

Back to Vicki.

She publishes her site and she adds her content. She is ready to go. We built a special system for publishing and unpublishing sites. We found that early users would put up content and not happy with the content. Especially the academic types. They wanted to wait, think about it, and test it out before it was published to everybody. We added this new feature into multisite that allows the user to publish their site. When Vicki is ready, she just clicks publish. If she wants to take it away, she can click "unpublish." It shows up on our directory thing. You can see that lower down on the slide.

This directory is a key feature because it exposes users to different sites and what it all offers. I never knew that Two Lane had a clay class. Another thing the directory does well is police sites. When people see their site is on the directory, they will update it, keep it fresh, or take it down or whatever. What we found with the existing multisite that Two Lane has is that so much of their websites stay stagnant because people forget they are there. The directory helps users know their site is there.

Some additional features to go outside of Vicki for the more general platform. This is something that is on our wish list of building. It is something we scoped out. We really want to integrate with other developers. There is no reason why our company needs to be the only developers working on this. There are great developers and employees and they should be working with the system and multisite and not scared that we are some overlords or we will take their work from them. We wanted to create an easy integration. One of the ideas we are still working on and I am excited about is creating easy continuous integration.

What a developer would need to do is to give you their repo address. If they have a new theme, plugin or whatever all they need to do is add in the plugin here and submit it to us. Once it is submitted, we will use tools to test it and make sure it meets standard requirements. If it doesn't meet those requirements, you are notified. If it does meet requirements, it is sent to administrators of the system and they test it on the staging development. If it is great, they launch it.

We really want to bring developers in. There needs to be more developers working on this project. It should not scare developers away or trim developers from the project.

Like I was saying, Vicki when she launched her site for the first time had prebuilt content. Prebuilt content is different than themes. Themes are CS's and PHP files. Templates are really just the way that content looks and feels on the page. Templates are a way to get started.

People can create and submit templates to us. If somebody created a great new blog site and they wanted to replicate it a lot. Maybe it was a sports blog they wanted to do for each sports team. All they would need to do is name their template, save it, and send it to us for review. We make sure the larger community can use it. If they can't, we will target it to certain users. Then we will launch it. Those are called templates and it is an easy system we have built.

We are also talking about advanced user roles. This will be a super robust system. Teachers have been using WordPress to teach and run their classes. There is no reason why a student should not be proud of the work they published and keep it. There is no reason why WordPress can't handle the traditional pedological approach. We are trying to develop the pedological process inside WordPress. This is exciting for me because I am passionate about bringing class work online and exposing it to the work.

The better you make these tools to fit the classroom, the more teachers and students will use it. I am hoping this feature will evolve over the years and maybe even become its own plugin for teachers to run on their single sites.

I will move to my development process. We developed a two lane platform in four phases. The first phase was setting prototypes and requirements. We did that a while ago. Tom Cheek was working with me from Two Lane IT. We worked with tons of developers and met with them. We were curious what they needed and wanted. Anyone who had an existing Two Lane site we looked at. You wouldn't believe how many projects I have been part of that has not done stakeholder interviews. It is so important. Once we go to the second phase with the design, you can go back to the stakeholder interviews and say why you chose this. It is a huge asset by having the stakeholder reviews.

We had our stakeholder interviews and designed multiple mock ups. We tested those mock ups. We tested them internally and asked lots of questions of them. It was a big process of figuring it out. The big thing for Two Lane was to maintain branding requirements as we did the UX. Once we had all the UX stuff down, we created the production beta. The production beta was the thing that went to users first. We went back to our stakeholders and we said here it is. It is going to change, but try it out. We did that and constantly reiterated on that. Finally we deployed our final beta and support documents. I need to caveat this project.

COVID has sent this timeline out the window. We were last on this in December 2019 hoping to launch around now. We are in this stopped zone. Whenever we are ready, we will deploy the final beta and get production up and going.

We had two themes. We worked closely with the marketing department to identify fun themes. We had a hullabaloo colors and other types of New Orleans like things. Another fun thing a student group or fraternity might use we called our Broadway theme. For the more refined folks and oficial stuff we made a St. Charles theme. We had these two different themes. They felt similar but definitely had a different aesthetic and style we pushed for.

The Broadway stuff really worked for sports teams and St. Charles worked for administrator.

We worked through intercom. We are constantly seeing what needed to change. When we needed to put out the beta, we were getting feedback and changing things. We would figure things out. We would squash the bug, put it on our list, or tell them what they are doing wrong. Every developer had their hands in these support documents and answering tickets. It helped everyone in the team understand what was wrong and what needed to be fixed. Hopefully we were pushing towards having a dedicated support team. It always begins with the developers themselves answering these tickets and finding out what a user thinks.

Our production beta like I had been showing you with the Vicki thing, we squashed the bugs in beta form. We made it big and beautiful and then launched it to our group. Hopefully we will launch it to everyone soon. The internet and COVID do weird things.

Again, this entire platform was built on top of multisites. We used different skins to make things unique. It is all multisite. It has all the multisite pieces you would normally see on a site. We authenticated. Thanks to Paul for supplying his plugin. He gave us a suggestion for a plugin he used for our system and it worked better than any other plugin out there. Kudos to him. We would not have had as easy of an integration if it was not for him. Everything is a single sign on. We have all the information on them as soon as they sign in, and we can relate content to them. If they are in the science department, we may have more lab templates for them.

We created custom plugins. We did a lot of work figuring out the architecture. We built specific plugins in their feature site. They were very accessible throughout the entire process. We have a core function plugin for some of the unique ones we built. We did skimming. We had a really cool integration with interfolio that allows teachers to instantly add their information from Interfolio into WordPress. Instead of a teacher writing out their CV and all their awards, they need to log in and all that information is already there. Teachers have liked that. Interfolio gave us a shoutout since we showed it to them.

We have a multisite tagging system. We created a directory block so you can search for all the sites on the system. We had the visibility control that has the publish and unpublish feature. User roles can turn the entire system into a pedological platform.

The final most important thing is that everything we did was open source. From the beginning, I was a real worrier for the open source. I felt terrible every time I built something from WordPress that I couldn't share with everybody. WordPress is meant to be shared with everybody.

We are slowly as we develop this thing, and hopefully there is more development on this platform, we are opening it to the larger community. In doing that, I hope every school has their own self service system. As other people adopt it, they can tell us what are doing wrong and vice versa. We can make a better system together.

That is one of the most beautiful things that it does. The other secret sauce that I have to share with administrators on why they are open sourcing everything. It is the cost effectiveness. Two Lane was paying so much money for support systems software. That stuff can be mitigated by a really good open source plan. You are using technology you don't need to pay license fees for and you have a gigantic audience and support system. It is an economic incentive to be open source. It is really hard for any proprietary tool to argue against it. If you have a skilled team, you will benefit economicly and morally by open sourcing all your content.

I close with being a huge open source promoter and encourage you to check this out. The more activity we have on that, the more we will post. Get in there and let us know if there is anything we can do. Thanks, everybody! That is it for me. Here is my contact information. I will now turn it over to questions and answers.

Room Host: That we have. This is right at home. From the QA we have a popular selection. I will try to get through as many as I can.

What did you use to skim the administrator side of the platform? A plugin or custom admin theme?

Presenter: We went through plugins and then we went and added our own custom theme on top of it. That was a tough thing. It is constantly changing. We are cognizant that if WordPress updates a class name, we need to update it. We are monitoring and keeping track of that. Eventually we would love to turn this into a Head List component where we are building from scratch. Now we just built in the custom plugin that skims it all.

Room Host: Did you create a plugin or custom code for customers?

Presenter: It is a custom we created. It is managing a plugin called Publish Press. We built it. Right now it is very simple. It is just custom roles with custom notifications. We built it from scratch. We hope to build it out. What we have seen in some of our other projects is that teachers have specific needs. For instance, on one of the sites, teachers submit their homework through the site. The teachers want to look at it, they want to know when it was submitted and all those things. As those needs evolve, we will update it. We used hooks to update the users. We built right into the WordPress system as it is.

Room Host: Since we are on the subject of plugins, someone asked what the single sign on plugin that was used for this project was?

Presenter: Paul created this plugin. It is called . . . let me get. wpDirAuth. I would highly recommend it. I will speak out the URL and it is gilzow.com. That is Paul Gilzow. His plugin was great. We tested every single one. His won. I can't say that enough.

Room Host: Paul is not in this session right now but he will get notifications that he was name dropped on this session. Speaking of features of the multisite, we had a question on how the publish unpublish feature worked.

Presenter: We have this little publish area and unpublish. Basically, WordPress multisite already has a meta field that says if the site is published or unpublished but they don't give the UI to change that. All we are doing is we are using the built in multisite data piece that is published/unpublished and giving the user control in that. If the user changes it, it will change to publish or unpublish. We use it for the directory point. If something is published, I will go way back on the screen. If something is published, it will show up in this directory. If it is unpublished, it won't show up in the directory. We also talked about the data and what sites to keep or not keep on the system. If something hasn't been published in three years, we might be able to take it out of our system.

Room Host: We are about two minutes left. I will try to get through one large question outside of plugin decisions. We had them ask if you were able to accomplish this in a year, what was your team size? Did you use external agencies?

Presenter: I could have this up and running in three months if it were not for the bureaucratic system that is necessary. We did it all internally. We have a great team. It is myself, my brother, Ezra, two other developers and a designer. With five people plus an IT admin Tom we were able to do it all ourselves. We did not need to outsource. Tulane was a lot cheaper than we spent on any license for a similar tool. Like I said, this could have been a four month thing for the right tool and size. We work fast and agilely. We are not doing unique things. We have the expertise of WordPress. So we are not building a lot of stuff. A lot of it is figuring out architecture and how it works.

The next time we do it, it will go even faster and we can learn more things.

Room Host: Fantastic. At that, you finished your time completely. We are at forty-five minutes past. Thank you. You have inspired a lot of multisite projects. Thank you for sharing your expertise on this project.

Presenter: Thank you. It's been fun.