The Geffen Playhouse

[Jonathan Lahijani]

I developed the new Geffen Playhouse website over the course of 2018/2019 and launched it in September 2019.  It has been perhaps the largest project I have been involved in.  The Geffen Playhouse went through an entire re-branding done by Base (including a custom font), and I worked with Teak on the new website.

Website
https://www.geffenplayhouse.org/

Wikipedia
https://en.wikipedia.org/wiki/Geffen_Playhouse

Base write-up
https://www.basedesign.com/work/geffen-playhouse-always-geffen-playhouse-always-new

Teak SF write-up
https://teaksf.com/work/geffen-playhouse-ticketing-ecommerce-website-design/

Another write-up:
https://www.laurentakayama.com/geffen

Their previous website was severely antiquated and it wasn't a responsive website (as of 2019!).  Instead, it forwarded mobile users to a "mobile-friendly" website on a different subdomain, which I think was hosted by a third party service.  However the data containing all the actors, shows, seasons, news and press articles were all in there.  So one major aspect of this website was de-duping and importing their data into ProcessWire, along with some post-import cleaning… that's ~25 years of data.

The site is built with UIkit 3 for the most part, and also uses FullCalendar for the large and small calendars.  There is a custom integration with AudienceView, their ticketing system, which is used to import all the performance showtimes of their shows into ProcessWire.  It's not the easiest API to work with (XML), but I eventually got it working.

Repeater Matrix is being heavily used for section-based page building.  Building out all the necessary matrix types took a long time as there was quite a bit of thinking what types and layouts we needed as we went along.  However the end result has given the editors a lot of flexibility.

ProCache is being used as well, including a CDN for all assets.  This is crucial because when opening season sales are announced, the site gets slammed, but with caching turned on, it's not a problem anymore.

On a deeper level, the site uses my new (well 2 years old now), universal and very opinionated base module that provides a menu builder, a standard set of fields/templates/pages, and a bunch of other tweaks that I tend to use on every site.

All the fields, templates and pages are set up in a streamlined and editor friendly way.  I wasn't able to access their previous CMS backend for various reasons (I only got the MySQL dump), so when developing the site and data model in ProcessWire, I was able to completely re-envision the editor experience and the data model without bias.

A quote from one of the marketing directors at Geffen Playhouse: "We absolutely love ProcessWire."

More details on my personal website:
https://jonathanlahijani.com/projects/geffen-playhouse/

[Ivan Gretsky]

14 hours ago, Jonathan Lahijani said:

Repeater Matrix is being heavily used for section-based page building.  Building out all the necessary matrix types took a long time as there was quite a bit of thinking what types and layouts we needed as we went along.  However the end result has given the editors a lot of flexibility.

Great job and write-up @Jonathan Lahijani!

Could you expand a bit on the RM based content builder? Maybe even post some screenshots or even videos, if that is allowed by the customer. We had a great conversation about content builders in the beginning of the year. And you are a named expert in the field, so would love to read/see/watch anything more detailed from you.

[Jonathan Lahijani]

7 hours ago, Ivan Gretsky said:

Great job and write-up @Jonathan Lahijani!

Could you expand a bit on the RM based content builder? Maybe even post some screenshots or even videos, if that is allowed by the customer. We had a great conversation about content builders in the beginning of the year. And you are a named expert in the field, so would love to read/see/watch anything more detailed from you.

I'll make a video of this in the near future but here's the extremely short version of the page builder journey I went on.

There are 2 approaches that ultimately make sense: section-based and component-based

Section Based:
This is the "intended" way repeater matrix (and similar fieldtypes in other CMSes -- WordPress ACF has flexible content, Craft has Matrix) is supposed to be used.  Each matrix-type represents a section with the necessary fields to populate that section.  No depth.

1. Pros
   1. easy for editors to understand
   2. they just need to put in the content and it will work; no need to worry about layout because it's baked in; hard to mess up
2. Cons
   1. not flexible / requires a lot of discussion to make sure all sections, fields and their variations are covered
   2. can't move content from one section to another
   3. can lead to field bloat

Component Based:
Each matrix-type represents a component (headline, text, image, video, description list, etc.).  Furthermore, 4 additional matrix-types for layout: section, container, row, column.  Depth is enabled as well as the new "family friendly" option which I pushed Ryan to implement earlier this year and makes this approach more usable.

1. Pros
   1. extremely flexible; closely follows YOOtheme Pro's approach but in a matrix-way
   2. can move content anywhere
2. Cons
   1. higher learning curve compared to section-based since layout and nesting is involved
   2. structures must be repeated over and over again since each component is independent
   3. uses many more pages behind the scenes

--

Which approach is better?  The answer is it depends on the nature of the content of the site and the technical ability of editors.  If the site has a level of consistency from page to page, the section-based approach would work better.  However if there is less consistency and/or the editors need and/or are willing to put in extra effort to build truly unique pages, then the component-based approach makes sense.

The thing is, you can actually use both approaches.  The matrix field name for the section-based approach that I use is called 'sections' and the component-based approach field name is called 'builder'.  My base module sets up these fields automatically and uses Mystique for all the settings.

You can add both the 'sections' and 'builder' fields to a template and the editors can decide which one makes more sense given a page's needs.  

[Ivan Gretsky]

Thanks!

Looking forward for to see the video. I am sure that just looking at the list of available sections/components and Mystique configs can give me a lot of inspiration.

And that part about automatic fields setup sounds magical. Is that base module or some of its parts open to read the code?

Sorry, got too exited))

[HMCB]

On 7/28/2021 at 2:20 PM, Jonathan Lahijani said:

the site uses my new (well 2 years old now), universal and very opinionated base module

Is this base available for others to use? I’d be curious if it could give me a head start on some upcoming projects.

[Jonathan Lahijani]

On 8/13/2021 at 1:06 PM, HMCB said:

Is this base available for others to use? I’d be curious if it could give me a head start on some upcoming projects.

I would like to do this, but right now I just don't have the time.  The module is in a state where it needs a significant amount of cleanup before it would be usable for people who are not myself.  For example, right now it forces you to install practically all the pro modules (FormBuilder, Matrix, ProCache, etc.) as they are dependencies.  Secondly, I've hardcoded various things in there at the moment (due to time constraints) that would have to be cleaned up.  Third, right now it's kind of in a frankenstein state of how it works with various CSS frameworks.  The goal is to make it work with UIkit3, Bootstrap5, or Tailwind2 (or none at all), but I have to finish making it work with each and do the proper OOP (right now it's a mess).  Also, the builder related stuff is constantly changing but nearly settled after 2 years (I've had to re-develop builder pages on a site 10 times once, I don't wish that on anyone).

Also keep in mind it forces the creation of a bunch of general fields which I would suspect might be a turn-off if you have a purist approach.  For example, I have a text field called "IP Address" that gets created.  There's not really a choice in whether you can keep it or not.  If you delete it, it will get recreated on a re-install or update.

I do wonder though if I released if it would take on a life of its own through contributions (even clean-up related work initially).  The vision of this module is to be "the best of ProcessWire" and from that it's highly opinionated.  Meaning, it forces the use of Markup Regions and setting() vs other approaches.  It uses a built-in menu builder based on repeaters (as opposed to something like MenuBuilder module).  It relies heavily on the Mystique field for the builder options.

I will make a video eventually.

[HMCB]

No worries @Jonathan Lahijani. Thanks for your efforts. Don’t make any special effort on my behalf. I just like to learn from other’s approaches. Take care.

[Outward]

Fantastic work Jonathan, you should be very proud of this project!