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.