ralberts

Thanks for your feedback. You're right, we haven't done any effort in making this site work without javascript turned on. Figures show that the amount of visitors without javascript (excluding bots and crawlers) is pretty much non-existent, so that was a calculated tradeoff.

Back in 2013 we at X-com built our very first ProcessWire empowered website: A-Z barbecue & gourmet. It has been running very well for the past 3 years. Technology caught up on us however, and in 2016 it was time for a radical redesign. The old website was not very mobile friendly and the actual shopping feature was iframed and delivery by a third party. Shopping was not very userfriendly either, which led us to believe that an improvement in design and usability was in order. All actual functionality is now handled by performing API calls and Iframes were removed. The new design is simple and straightforward and the first results look promising. The website went live about 3 weeks ago and since then conversion increased on all devices: Desktop 6,08% =>7,27% Tablet 2,48% => 4,01% Mobile 0,5% => 1,36% Go check 'm out! http://www.barbecue.nl http://www.gourmetten.nl http://www.a-z.nl

Ah, thanks for noticing!

At X-com we build and maintain ticketingsoftware, named Itix. About 20 Dutch Theatres run our software and since we've dropped maintentance on our own CMS, we're slightly migrating more and more of those theatres towards a ProcessWire powered website. Using various API's and synchronisation tools, all needed information and actions are provided to the ProcessWire frontend, resulting in a cool e-commerce solution which is flexible towards the client and scalable for us. Another one was released this week, go see the result at http://www.maaspoort.nl The design was done by http://www.dejongensvanboven.nl The technical implementation by us at http://www.x-com.nl Other Itix theatres running on ProcessWire include: http://www.schouwburgvenray.nl/ http://www.dnk.nl/ http://www.rabotheater.nl/ http://www.deleest.nl/ http://www.hof88.nl/ http://www.demeenthe.nl/ http://www.muziekgebouweindhoven.nl/

Ah, awesome stuff. Must've missed that. Thanks so much!

Hi Ryan, The grouping does sound like exactly what I need (totally missed out on that feature!), but does not seem to work: it produces the exact same query as without the grouping. Probably because I'm using the non-native Matrixfieldtype. It stores data in a table set up like this: Table: CREATE TABLE `field_availability` ( `pages_id` int(10) unsigned NOT NULL, `data` int(11) NOT NULL DEFAULT '0', `sort` int(10) unsigned NOT NULL, `matrix_column` int(11) NOT NULL DEFAULT '0', `matrix_value` varchar(255) DEFAULT '', PRIMARY KEY (`pages_id`,`sort`), KEY `data` (`data`), KEY `matrix_column` (`matrix_column`), FULLTEXT KEY `matrix_value` (`matrix_value`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 Testcase: $pages->find('template=accommodationtype,@pricetable.matrix_value=1,@pricetable.matrix_column=1178,@pricetable.data=1127'); $pages->find('template=accommodationtype,pricetable.matrix_value=1,pricetable.matrix_column=1178,pricetable.data=1127'); $queries = $database->getQueryLog(); foreach($queries as $query){ if (strpos($query, 'pricetable')) { echo '<pre>' . $query . '</pre>'; } } Output: SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN field_pricetable AS field_pricetable ON field_pricetable.pages_id=pages.id AND (((field_pricetable.matrix_value='1' ) )) JOIN field_pricetable AS field_pricetable1 ON field_pricetable1.pages_id=pages.id AND (((field_pricetable1.matrix_column='1178' ) )) JOIN field_pricetable AS field_pricetable2 ON field_pricetable2.pages_id=pages.id AND (((field_pricetable2.data='1127' ) )) WHERE (pages.templates_id=44) AND (pages.status<1024) GROUP BY pages.id SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN field_pricetable AS field_pricetable ON field_pricetable.pages_id=pages.id AND (((field_pricetable.matrix_value='1' ) )) JOIN field_pricetable AS field_pricetable1 ON field_pricetable1.pages_id=pages.id AND (((field_pricetable1.matrix_column='1178' ) )) JOIN field_pricetable AS field_pricetable2 ON field_pricetable2.pages_id=pages.id AND (((field_pricetable2.data='1127' ) )) WHERE (pages.templates_id=44) AND (pages.status<1024) GROUP BY pages.id

Great stuff this... great stuff indeed. One question, would it be possible to pick a specific value from the matrix? So on a certain page, I would like to spit out the value at row 2, column C, without having to loop the whole pricetable to find that specific value. My current implementation is quite inefficient: foreach ($accommodation->pricetable AS $p) { if ($p->row == $weekPage->id && $p->column == $pricePage->id) { echo $p->value; } } Thanks for a great module!

Thanks lads. The workarounds don't seem to work; so I'll head over to github and post the issue there.

Something that might work is the code below. But that might break several other selectors. I can't really oversee the effects of changing this. PageFinder::___getQuery() // use actual table name if first instance, if second instance of table then add a number at the end if ($subfield !== '' && $subfield !== 'count') { $tableAlias = $field->table; } else { $tableAlias = $field->table . ($fieldCnt[$field->table] ? $fieldCnt[$field->table] : ''); } $tableAlias = $database->escapeTable($tableAlias); Original: // use actual table name if first instance, if second instance of table then add a number at the end $tableAlias = $field->table . ($fieldCnt[$field->table] ? $fieldCnt[$field->table] : ''); $tableAlias = $database->escapeTable($tableAlias);

Hi there, According to http://processwire.com/api/selectors/#subfield a subfield selector defined as... template=accommodationtype,availability.column=1194,availability.row=1889,availability.value=1 ...should return all accommodationtypes where all availability restrictions match: availablity.column = 1194 AND availability.row=1887 AND availability.value=1 What actually happends (looking at the querylog), is that the availability field is joined 3 times, matching all 3 subfields seperately, then grouping the result and thus returning all accommodationtypes where either of the restrictions are met: availablity.column = 1194 OR availability.row=1887 OR availability.value=1 Is this intended behaviour, a bug or am I just missing something here? Perhaps using a different selector would do the trick? I can probably fix this in PageFinder::___getQuery(), but without a decent testsuite I'm not comfortable in fiddling about there The actual query executed is: SELECT pages.id, pages.parent_id, pages.templates_id FROM `pages` JOIN field_availability AS field_availability ON field_availability.pages_id = pages.id AND (((field_availability.matrix_column = '1194'))) JOIN field_availability AS field_availability1 ON field_availability1.pages_id = pages.id AND (((field_availability1.data = '1187'))) JOIN field_availability AS field_availability2 ON field_availability2.pages_id = pages.id AND (((field_prijstabel2.matrix_value = '1'))) WHERE (pages.templates_id = 57) AND (pages.status < 2048) GROUP BY pages.id Any help is much appreciated!

The multisite module is the one by Apeisa: https://github.com/apeisa/Multisite/blob/master/Multisite.module Only thing we've added is some additional handling for 404 redirects (so that every subsite can have it's own 404 page).

The BMW Dealersites is a collaboration of various BMW dealers, brought together in a multisite ProcessWire setup with centralized and per-dealer contentmanagement possibilities. For anyone interesed, below a quick glance at the multisite pagetree: BMW enforces strict design guideliness for all websites that are built carrying the BMW logo. The guideliness are extensive but can be considered a bit outdated, since they do not take responsive possibilities into account yet. We managed to implement a responsive setup nevertheless, still complying to the guideliness. Which was quite a struggle, I can assure you As mentioned, the Dealersites is a collaboration of various BMW dealers. The idea is that all dealersites are basically the same (fields and templates), yet content may vary. This enabled us to create a centralized content module, in which content can be added and copied to all underlaying dealersites, minimizing the efforts needed to add and maintain content. See the screenshot below for an impression on how this works. We have been experimenting with hosting a bit. The sites are hosted using various Docker instances on an Amazon EC2 server, and mails are sent using Amazon SES. In the near future we plan on implementing ProCache3 with Amazon CloudFront. If you need any info on our experiences with this, just drop a line in this topic or sent me a DM. We have used quite a few modules, but nothing exotic. FormBuilder was used to create forms, some of which are handled by a third party URL to have added functionality: shooting Leads to an external webservice for example. The dealersites: http://www.vanlaarhovenbmw.nl http://www.vanhooffbmw.nl http://www.demaassche-venlo.nl http://www.demaassche-echt.nl http://www.nobracars-uden.nl http://www.nobracars-helmond.nl http://www.story-denbosch.nl http://www.story-waardenburg.nl http://www.story-nijmegen.nl Splashpages: http://www.nobracars.nl http://www.demaassche.nl http://www.bertstory.nl Work was done by us at X-com

At X-com we build and maintain ticketingsoftware, named Itix. About 20 Dutch Theatres run our software and since we've dropped maintentance our own CMS, we're slightly migrating more and more of those theatres towards a ProcessWire powered website. Using various API's and synchronisation tools, all needed information and actions are provided to the ProcessWire frontend, resulting in a cool e-commerce solution which is flexible towards the client and scalable for us. Our latest and greates is Schouwburg Venray. Go check it out at http://www.schouwburgvenray.nl The design was done by http://www.dejongensvanboven.nl The technical implementation by us at http://www.x-com.nl

Thanks Felix, I'll keep that in mind. My colleague did most of the work with Twig, he may get back to you

Nope, not yet. Thanks for pointing this out, we will definately look into it.

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.

For the Rabotheater website we implemented the JS / CSS method described by Jan Romero above. It's basically as simple as changing the outer CSS class of the items on mouseclick (as described by MuchDev). The CSS takes care of the rendering of said class and displays a listview or a gridview depending on the outer class. Using Firebug in Firefox (or something equivalent for other browsers) you can easily see changes made to the source on toggling between list and grid view. And you can also see which CSS renders the items.

Thanks for your kind comments. 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 Aye, apparently he does

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

This is just awesome, I was just starting work on something like this when I noticed the push via IRC. Any estimations on to when the Pro version will be available? And will this support presetting (and hiding) filter values?

Had a short talk with Soma on IRC. To summarize and be complete: I thought of using the module to have 2 websites, each multilingual with their own domain for each language. I figured I could use the multilingual aliasses of each website to alternate the languages. Unfortunately it does not work that way. I assumed this could look something like www.firstwebsite.nl (pagename)www.firstwebsite.nl (alias) www.firstwebsite.de (alias) www.firstwebsite.en (alias) www.secondwebsite.nl (pagename)www.secondwebsite.nl (alias) www.secondwebsite.de (alias) www.secondwebsite.en (alias) Soma suggested to just use www.firstwebsite.nl/nl www.firstwebsite.nl/de www.firstwebsite.nl/en and the same for the other website. I'll see if I can tweak the module to support my needs. If not then I will probably resort to fiddling with .htaccess. Unless someone has a bright idea on how to solve this ;-)

Hi there, I'm trying this Multisite module in combination with multilanguage page names, but seem to be facing a bug. I'll add some screenshots which will hopefully clarify things. Little background on my installation: PW version 2.3.7 Language support page names 0.0.8 Soma's multisite module version 0.0.2, with the configuration below: www.msite.nl.frits www.msite.de.frits These domainnames are only active on my local development environment, so don't bother trying to browse them yourself My pagetree is as follows: The contents tab of this page: And the settings tab: Now when I browse to http://www.msite.nl.frits I get the default content of this page, as expected. However: when I navigate to the German domain http://www.msite.de.frits, I'm suddenly redirected to this URL: It seems like the the module only looks at the main page title, instead of the page names configured under the settings tab. I've looked at the code but am not quite sure how to fix this. It looks like the redirect is not issued in the Multisite module, but somewhere outside. Any help or insights would be much appreciated!

Thanks for the response Ryan. I already figured out that moving the code to a template file solved my problem. Enalbing output formatting is a valuable hint though, thanks!

Made a small workaround by adding the users language to the ajax request to get this to work: <?php require_once '../../index.php'; $data['markers'] = array(); $markers = array(); $affiliates = wire()->pages->find("template=affiliate"); $language = wire()->languages->get("default"); if (isset($_GET['language'])) { $language = wire()->user->language = 1010; } foreach ($affiliates AS $affiliate) { $marker['latitude'] = $affiliate->mapmarker->lat; $marker['longitude'] = $affiliate->mapmarker->lng; $marker['title'] = $affiliate->title->getLanguageValue($language); $data['markers'][] = $marker; } print(json_encode($data)); It feels a bit hacky and I guess there is a better way to achieve this. So any input is more then welcome, but for now I'm happy with this solution

Hi Interrobang, Thanks for your response. That might work, assuming I can fetch the language of the current user in my bootstrapped script. I cannot test this right now, but wire()->user->getLanguage() combined with your suggestion should do the trick. Thanks again!