Jump to content

Rabotheater.nl gets a new website


ralberts
 Share

Recommended Posts

Not our first ProcessWire powered website, but definately our most interesting one so far: http://www.rabotheater.nl

At Itix we build and maintain online ticketing software for theatres and cinema's. About 30 theatres across the Netherlands are powered by Itix. Our software has some form of integrated content mangement, but this "CMS" does not live up to current standards and client wishes anymore. We decided to move all frontend related content to a PW environment. Eventhough most data still exists within Itix, all website-specific enrichment is done within ProcessWire. PW gets it's data through export/imports (for complete datasets) and a method of triggering events, filling a jobqueue and updating specific single items.

Rabotheater is our first client moving to a PW powered website, but I'm confident many will follow.

http://www.rabotheater.nl

  • Like 16
Link to comment
Share on other sites

Thanks for your kind comments.

Very nice. Interested in hearing more about what you mean with job queue?

The Jobqueue resides mostly outside of Processwire, firing requests to a URL which updates PW's pages. The receiving end gets the data and uses PW's api to insert, update or unpublish pages. In order to offload peak-moments we decided to implement a queue. Imagine an import is done in our ticketing software; this would fire thousands of events to ProcessWire if we didn't use a queue to balance requests.

At the moment all is running well, but theatres tend to create a hype when the new season starts and visitors will come in masses, wanting to get the best seats for their favorite shows. It will be interesting to see how ProcessWire will cope during this period. We intend to do some performance testing in the near future. The website is running without cache at the moment, but we may end up using ProCache or a proxy cache to keep server requests at a minimum. All user-specific content is gathered (cross site) with Ajax, thus Proxycaching or Procache are still possible.

Modules we have used include Form Builder, Template Twig Replace (and data provider), Lister (which makes the backend far more user-friendly, great addition!), Ajax Search, Image Cropping, Profields, Batcher... and many more :rolleyes:

And what a surprise to see Urbanus is still doing performances after so many years.

Aye, apparently he does :P

  • Like 4
Link to comment
Share on other sites

Beautifully build. Can you tell more about the way you approached the filters "genres" en "maand".

Clicking on a filteroption for genre or month reloads the page with an altered URL (using javascript). The selector itself is a ProcessWire API selector:

$pages->find('show_status=geannuleerd|reserveren|uitverkocht'.($templateSelector?', template='.$templateSelector:'').(count($genreIds)?', genre_select='.implode('|',$genreIds):'').', from>='.$from.', from<='.$until.', sort=from');
		

We're a bit worried about performance though. The filter and search implementations aren't cached and a complex API selector does perform quite a few queries. We may move to ElasticSearch or something similar in the future.

Link to comment
Share on other sites

Very nice site. Also nice to see people using TemplateDataProviders and TemplateTwigReplace. If you've got any suggestions on improving the modules let me know.

If you got questions concerning elasticsearch: We're just about to release a website which makes use of elasticsearch and modified ElasticSearchProcessWire quite a bit to fit our needs. It's really easy once you got into it.

Link to comment
Share on other sites

@felix: I haven't used twig in this project as much as I’d liked to do. For now we only implemented it for the parts that needed to be rendered both client and server side. The overview of shows is rendered server-side (we want the overview page to be indexable by search engines), but to generate the shopping cart, we needed to have the same chunk of code generated in javascipt (the data for this is fetched cross-domain from our backend system). So for that we used twigjs. I wanted to replace all php-templates with twig-templates so we could extend templates and so, but didn’t had the time ;)

Same goes for the data providers. They are only used for the twig templates and there for not used that much. I hope to refactor some of this to make proper use of both modules. When we do, we’ll post it here somewhere!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...