Sakyadhita is in a bit of a bind right now, as they have deployed a new website, but it is only half done, they can’t update it, and the developers have gone.
Can anyone help out? They may be able to provide some funding for this, but I wouldn’t bet on retiring from it!
I’ve recommended to Ven Lekshe Tsomo that they bin the current site and start again. Personally I would build something like this as a static site with Jekyll or whatever, but that decision depends on both the developer and maintainers.
Happy to help out if it’s not too much effort, so it depends on the amount of content they have.
I can create a static site hosted on Github, but the issue is how can they easily update content themselves rather than relying on me. I could use something like tinacms.org or even decapcms.org but I did this for a friend and she found it difficult to edit so she switched over to wix.
I would strongly recommend against using Wordpress. That always seem to result in dukkha for all involved.
PS - if it is a lot of content I’ll have to bow out. Much of my spare time these days is spent on writing my Pali textbook, and in the last few days I have been contemplating starting a translation of Rūpasiddhi.
This is actually a perfect use for Wordpress. With Wix you are completely locked in to their platform. Wordpress is very easy for site owners to maintain after the developer is done.
Of course any platform will give problems if it isn’t done well. And the ease of use WP has makes it also easy for people to install endless plugins that wind up causing problems. It’s usually the plugins that cause problems. But a simple site like this shouldn’t need many if any at all. And the chances of finding someone skilled in WP administration/design is far higher than finding someone who can use whatever the latest popular flavour of static site builders is.
If the current developers were using WP then it would be trivial for someone else to pick up where they left off. In fact, if they had gone with WP they wouldn’t have needed a developer in the first place.
It is, as always, a trade off. But for a site like this I don’t think any speed advantage you would get from using a static site would be outweighed by the difficulties in adding content.
This may have been true even a few years ago, but the problem is Wordpress is in the midst of a very painful architecture transition to Full Site Editing and Blocks. The majority of existing Wordpress web builders are not familiar with it, and are either using the old architecture which will become obsolete or even worse still using page builders like Elementor.
Although the platform is technically open source, Wordpress sites are incredibly bespoke. If you use a page builder, you are locked in to a proprietary tool. If you are brave enough to use FSE and blocks, you’ll end up in a design that’s highly dependent on the FSE design and the specific blocks you are using, making it very hard to transition into another design, let alone a different platform.
I’ve spent the last few years migrating all the web sites I have created, and a few others as well, away from Wordpress. On one site, which uses Blocks, I’ve had to export the site in XML and write a custom XML parser to refactor the content. The ones written using page builders are horrible, better off to bin and rewrite.
The ideal solution for a simple website is a static site as @sujato suggests, but that requires someone to be familiar with (a) how to use a Github repo (b) how to edit in Markdown and (c) familiarity with a static site builder. This is still conceptually easier than learning the intricacies of FSE on Wordpress, but may be a leap too far for some.
If someone from Sakyadhita is willing to take on the challenge, I am happy to help mentor and guide them, and also assist in transitioning to a static site. Ultimately, I believe the owner of any website should have the self sufficiency to create and maintain content themselves, rather than relying on external help.
The advantages of Wordpress are that it scales and caters for dynamic content, especially search and comments, with a reasonably user-friendly interface. It’s pretty much the default for something like this, but for me, I’m like why spin up millions of lines of code to deliver a few HTML pages? They probably don’t want comments, and these days search can be better handled on the front end for a small site; a static site builder like Rocket bundles instant search right away, boom, it’s all in your browser.
They look neat.
But anyway, it really depends on the stakeholders. Any of these can make a fine site, just so long as people are happy.
That’s great Christie, would you like to get in touch with Ven Lekshe and discuss the project scope?
Happy for her to contact me through this forum or email. If you can arrange an introduction, that would be great. I don’t like cold calling people I don’t know.
I do have a static site template (actually I have several) using the Astro framework that I’ve built that I am happy for others to use:
But, as I mentioned, it assumes someone is familiar with Github, and Markdown. All other features, like search etc. are provided by the template. Also any significant design changes will require knowledge of Javascript, CSS, HTML et al (good luck!). I use TailwindCSS which means it is easy to “import” an existing TailwindCSS design.
Yes, don’t use full site editing. It’s much too early to adopt it unless you really need it, which most people don’t. There are thousands of very good themes out there under the old system. Blocks are fine. Especially for a site that looks like it is just text and images. Don’t use page builders under any circumstances, lol. They were meant to solve a problem that no longer exists.
It also depends on what they want the site to be. If it’s just like a brochure site where the content rarely changes, then WP might be too much. But if they plan on regularly publishing content, there are lots of advantages to WP.
Nice, that looks great. Astro is super-cool, I’ve thought of using it myself. As for Tailwind, I understand its usefulness in this case, but my goodness, all those classes feel like bugs crawling under your skin.
I mean, whether this is a good thing depends on who is doing the redesign. In many cases, locking people in and not letting them mess things up is all win, no downside.
The secret to “grokking” Tailwind is that it transform web design from CSS (which is stupid and complicated because of inheritance) into HTML (which is linear and easy). But I agree, all those utility classes creates a cognitive burden.
The trick to using Tailwind is that it’s infrastructure. You don’t actually have to learn it - you can use it “naively” by searching the Internet for a design you like, and then copying and pasting all the HTML into your own site. Since it’s NOT based on an object oriented inheritance model, copy and paste just works you don’t have to do complex merging of CSS. So it creates an ecosystem where you can just buy, borrow or “steal” someone else’s design very easily to incorporate into your site - not just the entire design, but bits and pieces.
The main downside of Tailwind is that it generates a massive amount of CSS utility classes which needs to be loaded. This can be filtered down to just the classes being used, but there are several alternatives (such as UnoCSS) that just generates these utility classes on the fly, so you are always using a minimum set. That’s cool.
Just to let everyone know, we have managed to resuscitate and revive the Sakyadhita website and it was deployed into production yesterday.
The old website was written by UCSD students, and is based on a SERN stack (SQL, Express, React Node) and deployed on Heroku. Unfortunately, the backend database has stopped working, which is why the website seems dysfunctional, as it is no longer able to access content. We have been unsuccessful in gaining access to Heroku, as we have lost the 2factor credentials.
However, I have managed to find an early version of the source code on GitHub. That, combined with reverse engineering the currently deployed code (surprisingly, it is easy to hack into React code for a deployed application - security researchers, take note!)
Based on that, I was able to recreate a working copy of the website. I then collapsed everything into a static web app by throwing away the entire stack and reposting the content using Astro in a Github repository. I have retained the React components to preserve the existing web design. There are some issues with the design, but I simply do not have enough time to do a complete redesign. If anyone is willing to volunteer, please reach out.
My role in all of this is minuscule. The bulk of the work is done by Venerable Lekshe in updating the content of the website, so you can now see beautiful photos, updated conferences, newsletters and publications, as well as branch information.
Curious what’s left to be done here? Are they still wanting a full redesign? Is the content left on the inaccessible heroku instance just considered gone for good?
Sakyadhita would like integration into Constant Contact (currently all the forms end up as email messages).
Also the design can be euphemistically referred to as “student quality” - it’s in a mixture of bespoke CSS, dynamic React (if (mobile) { …}), Bootstrap and Material UI, so it’s possible each part of the design is created by a different student.
Sakyadhita is happy with the overall look and feel, but some things can be improved. It would be nice to rewrite as pure Astro components using just one consistent framework. Also some pages (like conferences and publication categories) should probably have distinct URLs rather than dynamically generated, so that they can be indexed by search engines.
