Leaderboard

Now also available in the ProcessWire Module directory for direct installation via ProcessWire: https://modules.processwire.com/modules/page-hit-counter/ ?

I often use the AdminCustomFiles module to append CSS and/or JS files. You can scope them by Process Module.

It's not hard to implement yourself. Create a template with a PHP file where you: Parse and sanitize all relevant information from the call (page id, filename, width, height, other options/actions) Retrieve the page with the given id Instantiate a PagefilesManager object with the page as the parameter Retrieve the image by calling getFile on the PagefilesManager Call size() on the image with necessary parameters/options Call $session->redirect() with the url of the object return by the site() call Here's a quick&dirty implementation:

Troll Driven Developer

i incorporated those elements, so those are in the module now; Should be tested by someone though, eu region on the forked version. https://github.com/outflux3/WireMailMailgun/blob/master/WireMailMailgunConfig.php#L18-L27 https://github.com/outflux3/WireMailMailgun/blob/master/WireMailMailgun.module#L197-L205

Version 1.2.2 as new master version available In version 1.2.2 a new option was introduced which allows to send page hits to templates which are not directly viewable or cannot be tracked automatically. This allows you to implement tracking that best fits your environment. An example with jQuery can be found in the first post.

The new website is OK, but the docs are unreadable for me. The contrast of the black code background with the white pages make my eyes hurt like crazy... Fix that please!

New version online: 1.1.2 The selector for the finder is now always stored as string, but can be retrieved as string or array - getSelectorStr() or getSelectorArr() This can be useful to share code for grids that are similar but need little adjustments, like one grid shows all available trainings, one grid shows only trainings that where booked by the current user: include(__DIR__.'/trainings.php'); $finder->setSelectorValue('client', $this->user); $finder->addField('done'); $this->setData($finder);

I am going to ask on StackExchange but I got another (magic) find, which give incredible performance on InnoDB schema. Adjusting `innodb_buffer_pool_size` (it need to be calculated) give better result than those in the above screenshots... The query to calculate the size to set based on the current data set : SELECT CONCAT(ROUND(KBS/POWER(1024, IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.49999), SUBSTR(' KMG',IF(PowerOf1024<0,0, IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_innodb_buffer_pool_size FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables WHERE engine='InnoDB') A, (SELECT 2 PowerOf1024) B; So for my DB I needed to set the var to 2GB (still not 100% sure) but the result are there - lower than in my previous screenshot : From 18s to 4s : From 96ms to ˜6ms : ? ?

@apeisa: this is just for FieldtypeComments and documented on the details tab for comments fields, where it can be used.

RockFinder now supports array-syntax, which makes the code a lot cleaner:

It is possible that the admin page was named differently than the default when PW was installed. In that case, you can determine the correct name (= path) from the entry in the "pages" table for the page with id 2.

The Page Hit Counter module for ProcessWire implements a simple page view counter in backend. Page views of visitors are automatically tracked on defined templates, with monitoring of multiple page views. This gives you a quick overview of how many visitors have read a news or a blog post, for example, without first having to open complex tools such as Google Analytics. This module quickly provides simple information, e.g. for editors. Or, for example, to sort certain news by most page views. For example for "Trending Topics". Works with ProCache and AdBlockers. With a lightweight tracking code of only ~320 bytes (gzipped). And no code changes necessary! In addition GDPR compliant, since no personal data or IP addresses are stored. Only session cookies are stored without information. In addition, there are some options, for example filtering IP addresses (for CronJobs) and filtering bots, spiders and crawlers. You can also configure the lifetime of the session cookies. Repeated page views are not counted during this period. It is also possible to exclude certain roles from tracking. For example, logged in editors who work on a page are not counted as page views. Sort by hits and access page views (hit value) Each trackable template has an additional field called phits. For example, you want to output all news sorted by the number of page views. // It is assumed that the template, e.g. with the name "news", has been configured for tracking. $news = $pages->find("template=news, sort=-phits"); To output the page views of a tracked page, use: echo $page->phits; Example: Reset counter per API $modules->get("PageHitCounter")->resetPageViews("template=whatever", false); Example: Tracking a page hit via API and jQuery If you want to track a template that does not represent a full page to automatically inject a tracking script, you can define allowed API templates in the module that you can track. Below is an example of how you can track a click on news tag using jQuery. This will allow you to find out which keywords are clicked the most. For example, you can sort and display a tag cloud by the number of hits. Suppose your keywords have the template "news_tag". The template "news_tag" was also configured in the Page Hit Counter Module as a trackable API template. Example PHP output of keywords / tags: // Required: the data attribute "data-pid" with the ID of the template to be tracked. echo $pages->find("template=news_tag, sort=-phits")->each("<a href='{url}' class='news_tag' data-pid='{id}'>{title}</a>"); Example Tracking Script with jQuery: /** * Required: Data attribute "data-pid" with the ID of the news tag template * Required: Send the POST request to the URL "location.pathname.replace(/\/?$/, '/') + 'phcv1'" * Required: The POST parameter "pid" with the ID of the template */ $(function(){ if($('a.news_tag').length > 0) { $('a.news_tag').each(function(){ var tPID = $(this).data("pid"); if(tPID) { $(this).on("click", function(){ $.post(location.pathname.replace(/\/?$/, '/') + 'phcv1', {pid: tPID}); }); } }); } }); So simply every click on a tag is counted. Including all checks as for automatic tracking. Like Bot Filtering, Session Lifetime, etc. Notice: Tracking with URL segments If the option "Allow URL Segments" is activated on a template, the hits are only counted if the base URL of the page is called. If you want the hit to be counted even when a segment is requested, you MUST configure the segments in the template configuration. How to do this can be found here. If you use dynamic segments, configure them as RegEx. There is currently no other option. The problem is that the Page Hit Counter hooked into the PageNotFound process. If URL segments are allowed but not defined, a 404 is never triggered. This means that the Page Hit Counter cannot be called. New since 2.0.0: Ignore URL segments If a template has URL segments configured, each hit on a different segment is counted as a new hit. Enable "Ignore URL segments" so that dynamic segments are not counted individually on the base template / page. New since 2.0.0: Use cookieless tracking (Experimental) Enable this option to not use individual cookies for tracking or if you have many different pages you want to track. The limit for cookies is 50 per domain for all cookies on the page. If the option is enabled, PHP session storage is used. Downside: you can't set the lifetime higher than configured in your PHP.ini and the session will be terminated as soon as the browser is closed. Upgrade note for 2.0.0 from previous versions! Version 2.0.0 requires an update in the database schema, so that additionally the date of the last access / hit on the page can be displayed ($page->lastPageHit). To make this possible, you have to do the update via the upgrade module, upload the ZIP itself and do an update directly via the backend AND DO A MODULE REFRESH DIRECTLY AFTER UPLOAD/UPDATE. If you do not do this, you will get an error that a column is missing in the database table. _______________________________________________________ Background: This module is the result of a customer requirement, where the editors are overwhelmed with analytics or no tracking tools were allowed to be used. However, a way had to be found to at least count page views in a simple form for evaluations. Furthermore, by using ProCache, a way had to be found to count views of a page without clearing the cache. _______________________________________________________ Pros Automatic Page View Tracking Lightweight tracking code, only ~320 bytes (gzipped) No code or frontend changes necessary Works with ProCache! Even if no PHP is executed on the cached page, the tracking works Works with browser AdBlockers No cache triggers (for example, ProCache) are triggered. The cache remains persistent GDPR compliant, session-based cookie only, no personal information Filtering of IPs and bots possible Exclude certain roles from tracking Ability to reset Page Views Works with all admin themes Counter database is created as write-optimized InnoDB API to track events for templates that are not viewable No dependencies on libraries, pure VanillaJS (Automatic tracking script) Works in all modern browsers Pages are sortable by hits Cons Only for ProcessWire version 3.0.80 or higher (Requires wireCount()) Only for PHP version 5.6.x or higher No support for Internet Explorer <= version 9 (Because of XMLHttpRequest()) No historical data, just simple summation (Because of GDPR) Segment URLs can only be counted if the segments are defined Planned Features / ToDos API access to hit values Since version 1.2.1 Possibility to sort the pages by hits (Request by @Zeka) Since version 1.2.0 Don't track logged in users with certain roles (Request by @wbmnfktr) Since version 1.1.0 Possibility to reset the counter for certain pages or templates (Request by @wbmnfktr) Since version 1.1.0 Better bot filter Since version 1.1.0 Disable session lifetime, don't store cookies to track every page view (Request by @matjazp) Since version 1.2.1 Option to hide the counter in the page tree (Request by @matjazp) Since version 1.2.1 Option to hide the counter in the page tree on certain templates Since version 1.2.1 API to track events for templates that are not viewable Since version 1.2.2 Cookieless tracking Since version 2.0.0 Show last hit Since version 2.0.0 Ignore URL segments (Request by @bernhard) Since version 2.0.0 Add hookable method after pageview was tracked (Request by @bernhard) Since version 2.0.0 Changelog 2.0.0 Feature request: Add hookable method after pageview was tracked (___pageViewTracked($pageID)) (Requested by @bernhard) Feature request: Ignore URL segments option (Requested by @bernhard) New: Cookieless tracking New: Show date of last hit Update: Botlist Enhancement: Documentation improvement 1.2.7 Feature request: make buildPageListHitCounter-Function public (Requested by @bernhard) 1.2.6 Bug-Fix: Set the counter of a cloned page to 0 Enhancement: The function for resetting counters is now available in the module as a public function to reset counters via own scripts on the API side (Request by @VeiJari) Enhancement: Documentation improvement API reset 1.2.5 Bug-Fix: When counting 404 hits, cookies are no longer set. The session lifetime is deactivated for the 404 page Enhancement: Documentation improvement regarding URL segments 1.2.4 Bug-Fix: Resetting the counters on system pages (e.g. 404) does not work (Reported by wbmnfktr) Bug-Fix: Tracking endpoint is logged as 404 if module "Jumplinks" is installed (Reported by wbmnfktr) Enhancement: Corrected few typos (Merged from Sergio #6 – THX!) 1.2.3 Bug-Fix: Tracking script triggers 404 if pages are configured without slash (#3) Reported by @maxf5 Enhancement: Reduction of the tracking script size if it's gzipped (~320 bytes) Enhancement: Documentation improvement Enhancement: Corrected few typos 1.2.2 New feature: API to track events for templates that are not viewable Enhancement: Documentation improvement 1.2.1 API access to hit values Use $page->phits Bug-Fix: No tracking on welcomepage (Reported by wbmnfktr; Thx to matjazp) Bug-Fix: Tracking script path on subfolders (Reported by matjazp) Bug-Fix: Tracking on pages with status "hidden" Enhancement: Change database engine to InnoDB for phits field Enhancement: Option to disable session lifetime set session lifetime to 0, no cookies Enhancement: Better installation check Enhancement: AJAX Request asyncron Enhancement: Reduction of the tracking script size by ~20% Enhancement: Option to hide the counter in the page tree You can output the counter with the field name "phits" Enhancement: Option to hide the counter in the page tree on certain templates Enhancement: Option for activate general IP validation Enhancement: Reduction of tracking overhead up to ~30ms Enhancement: Better bot list for detection 1.2.0 New feature: Sort pages by hits – New field phits Migrate old counter data to new field 1.1.0 New feature: Exclude tracking of certain roles New feature: Reset Page Views Better bot filter and detection 1.0.0 Initial release Notes By default, the page views are stored as INT in the database. This allows a maximum counter value of 4.2 billion views (4,294,967,295) per page. If you need more, change the type to BIGINT directly in the database. But I recommend to use Google Analytics or similar tools if you have such a large number of users. _______________________________________________________ Download GitHub: ProcessWire Page Hit Counter (Version 2.0.0) PW Module Directory: ProcessWire Page Hit Counter (Version 2.0.0) Install via ProcessWire (Classname): PageHitCounter _______________________________________________________ Update information If you have used version 1.2.1 from the DEV branch, please replace it completely with the new master version. Old stable version Download GitHub: ProcessWire Page Hit Counter (Version 1.2.7)

Oooops ?

Glad Admin Actions was useful for you, but just keep in mind that I was actually referring to the new Admin Tools panel in Tracy. Also, regarding the 'Copy Content to Other Field' in the Admin Actions module - did that actually work for the map data? I haven't tested it with multivalue fields, but if it worked, that's great. If it didn't, then it is something I should enhance it to do at some point.

I have already mentioned this in the comment section of the very first blogpost of Ryan showcasing it. Luckily I use the Dark Reader chrome extension to browse most sites anyway, but it would be nice to see a lot less contrast. Better yet, a native dark mode for the site would be welcome. We have just been presented with a nice example: https://processwire.com/talk/topic/20584-schwarzdesign/ (click the sun icon of the site in the top right corner).

Seems to have to do with the status field, which is for pageStatus. The line 195 in PageFinder.php returns this: I solved it with using a different query. I only used status=1|2049 before, because "include=all" did not work, and I even had unpublished pages in my result. And that was what I wanted. Show only published pages, or show them all. Don't know why it did not work before, but now it does again.

Thank you so much adrian. I had been using your Admin Actions module for other things. Super useful. I should have thought of trying that sooner. I have first applied 'Copy Content to Other Field', then used 'Delete Unused Fields'. Both no problems. More clean-up work to do before I can declare victory. I would be pleasantly surprised if the data really is still there, but at least the old fieldtype is gone. Will report back...

The new rockfinder updates make it easy to extend grids: Extending Grids Sometimes several RockGrids are very similar and you don't want to duplicate your code. You can create one base file and include this file from others: // trainings.php $finder = new RockFinder([ 'template' => 'training', 'sort' => 'from', ], [ 'first', 'from', 'to', ]); $finder->addField('coach', ['title']); $finder->addField('client', ['fullname']); // trainings_booked.php include(__DIR__.'/trainings.php'); $finder->setSelectorValue('client', $this->user); // only show trainings of current user $finder->addField('done'); // add column to show if the training was completed $this->setData($finder); You can then create another file, for example trainings_available.php to show all trainings that are in the future and available for booking: include(__DIR__.'/trainings.php'); $finder->setSelectorValue('from>', time()); $finder->setSelectorValue('client', null); // client must not be set -> means available for booking $this->setData($finder);

@adrian Installed. Works like a charm, excellent module, Adrian! Cheers!

Yes, it iterates the page's assets directory, checks every file if it is a variation of the current image and, if yes, recreates it with the constraints encoded in the variation's filename.

I think the best explanation is directly above that method: So, as I understand this, it tries to rebuild variations. But limited variations, 0 = without suffixes, without crops, etc. (read on above). But to know which variations are belong to an image, the variations have to exist! (It gets all variations and then try to determine how they were build, what seems to be simple for mode = 0, but becomes more and more special and indefferent with higher modes). HTH ?

Wasn't aware of that - but found the blog post: https://processwire.com/blog/posts/processwires-roadmap-in-2015/ 1 hour ago, adrian said: The advantages of using this _OR_ syntax are explained in this blog post: https://processwire.com/blog/posts/processwire-3.0.40-core-updates/#getting-one-field-or-another-from-a-page

It's the same with any search term ending with the open bracket, f.e. config( - with or without $. Edit: Not an issue of the missing closed bracket: Same with config() etc.

@ryan - just found another "Internal Server Error" on the new website for you: https://processwire.com/search/?q=%24page( You can get to this by typing: $page( in the live search and hitting Enter

Just in case you weren't aware, the second approach of $page('headline|title') already works. It was documented in a blog post some time ago, but I can't seem to find it at the moment. It even works like $pages('template=basic-page') etc. Basically variables that act like a function. The other option we have which I had actually forgotten about is: $page->headline_OR_title

I'm using 5.7 both on dev and live. Sorry, no idea ? http://smalldatum.blogspot.com/2017/06/sysbench-for-mysql-50-51-55-56-57-and-8.html , while http://www.oaktable.net/content/mysql-56-vs-57 says they perform quite similar. Maybe 5.6 has a problem with those subqueries?

Thanks @BitPoet! I thought it was something more generic, but now it makes sense why I have missed it ?

Thanks for the update - Would you have an idea why my queries are running so much faster on mysql5.7 than mysql5.6 ? What is your version on your dev platform ? Did you tested the two server version on your side ? Check. I switched my MySQL server version on MAMP from 5.6 to 5.7 and when I clicked a button which execute quite big query, it was, oh wow, instant. Switched back to 5.6, the query took like 8 to 12 52 seconds ? Still, I didn't investigated what's going on, but result... and the same happened on a Windows Server with MySQL 5.6/5.7 upgrade. Edit: Another one looking through millions of pages...

Yes, this is the response from the server. Yeah... It never crossed my mind that I should mention this somewhere, sorry. I don't like to update on github when I'm not sure it works and this change was just a quick fix... Make sense. Give me some time to think about possible solutions. Probably the best option would be separate list of options for admin (backend?), what we have now, and for API (frontened?).

Thanks, I have overseen this easy approach. Thanks to all for the help. I think we can close this thread now. If you like to have a look on my pages: https://tsvwesthausen.de

Hey @ryan, Just wanted to say a big thanks for making all those API examples on the home use the same approach, eg $page and $pages, and also for changing the image and save ones so they will work without errors. Thanks for listening to the community on this and sorry if it seemed we were hassling you ? Just one possible suggestion, although I am really not sure if this is a good idea or not. What do you think about: $page->headline_OR_title or: $page->{'headline|title'} or: $page('headline|title') instead of: $page->get('headline|title') For some reason these just seem to fit better to me when it comes to accessing a page's field values because I think of "get" and "find" as being more about getting a child/children of the page with a selector, rather than output a field or property of the page. Maybe it's just me though ? Did you have any thoughts on the idea of a sandbox console for users to play with?

@modifiedcontent - I have added that new "Delete Module" option to the Admin Tools panel. It will handle deleting modules when there are fieldtypes connected to the module and also when there are other modules that require the module you're trying to delete. I haven't tested it with a "broken" situation like you are describing and it actually probably isn't what you want because it will automatically delete the connected fieldtypes, so there will be data loss, so this is probably not what you want. Actually, now that I think of it, maybe the "Change field type" Admin tool will help you convert to the leaflet fieldtype?

Hey @Macrura, so glad you are taking this on. Agree it is stable, just needs a little love. In the fork made by @gebeer this supports the regions US and EU, would be great if you could get this into your fork.

Hi @flydev, have you got to test it with Form Builder? Thank You.

A few more minor bits and pieces... The left-side-only border on the three columns under the home page code samples looks a little off: It would look better if the borders were only on the inside edges of the columns, like the three column example in the footer: I think others have already commented about the blog overview layout. I find this layout confusing to parse because the box alignment is stronger vertically than it is horizontally, which makes me scan the posts top to bottom when actually the order is left to right. Having equal box heights within each row would improve this somewhat but I think there will still be some confusion for readers trying to work out the order. Maybe we should consider an entirely different layout for this page? Also regarding the blue box style - the are some small issues with the little circles on the corners. Sometimes they are stacking behind a neighbouring box so the line goes through the circle instead of behind it. This can be seen in the screenshot above. And perhaps there should be a circle in every corner of each box (it doesn't matter if the circles are doubled-up where two boxes meet) because the visual logic of where the circles are missing doesn't make much sense in some places: Lastly, I spotted a couple of little issues in some code blocks. 1. LSEP character showing here: https://processwire.com/docs/start/templates/ 2. $ variable symbol sometimes gets wrong colour here: https://processwire.com/docs/selectors/

True, for example, I didn't written any test for our frontend, but the backend and the module managing the transactions with financial data is fully unit tested, and it's required (while writing that, I am thinking on what we discussed on Github about the example of the float type vs the integer one for managing financial data; Imagine the things without test... houston.. ?‍? ).

Just a few days before christmas we relaunched our own agency website at schwarzdesign.de using ProcessWire! The old Drupal-based site was getting a bit outdated, we wanted to rebuilt it with fewer, more focused content pages, clean & minimalistic design and better performance for mobile visitors. Note that the site copy is only available in German. After a couple of successful ProcessWire projects such as Engfer Consulting and Joachim Kobuss, we decided to use it for our own site as well, mostly for it's small footprint and developer-focused API. We also have a dedicated ProcessWire page on our new site, check it out here! Modules used ProFields Automatically Link Page Titles TinyPNG Image Compression Color Tracy Debugger Sitemap Duplicator ALIF - Admin Links In Frontend A focus on content We went for a minimalistic approach with a limited set of design elements to highlight our content, which is mostly copy about our services and approach to web design. The two-column layout is built with a single Repeater Matrix section with fields for left and right copy, left and right images and a couple of display options for column width and alignment. Other Repeater Matrix types include a full-width image with some additional links (used on the homepage), teaser sections for current news and projects as well as a list of services. We used dedicated page types (templates) for services, projects and news. This allowed us to use those as taxonomies for our reference projects, and create cross-references to those pages in one go. For this purpose, there's also a dedicated CMS template and pages for all Content-Management-Systems we use, allowing us to categorize our projects and news in regards to the CMS used and show appropriate pages in the recommended content sections. Performance Loading times become ever more important with the rising amount of mobile traffic, both for the bounce rate and for SEO purposes. For client-side performance, we got rid of all external libraries (CSS and JavaScript). All CSS is written in SASS; we use a very stripped down version of Bootstrap 4 that includes only the grid system, the utility classes and a select few of the components. We also avoided the components requiring jQuery, allowing us to get rid of jQuery entirely. The few interactive parts of the site (flyout menus, the theme switch, adding the blur filter for the background image on scroll) are written in simple vanilla JavaScript. Server-side, we use the ProcessWire page cache to minimize server response times, as well as Cache-Control headers and GZIP compression to make sure all assets are as lightweight as possible and cached client-side. One problem we had were the large header images requiring transparency. We ended up combining a couple of approaches to minimize image loading times: SVG assets where possible (for example, all the service pages (Kompetenzen) use SVG for the header images. Responsive images to serve the smallest possible image for each device. PNG compression using the TinyPNG service and the TinyPNG module. This had possibly the highest impact, sometimes reducing the image size by about 80%! Design highlights One of the adornments of the site are the large, variable sized header images. Position and size can be controlled through the backend: We built display settings for size in viewport width or height, vertical and horizontal alignment as well as optional offsets. The header images are fixed to the viewport, so they always stay in the background. The blurred background uses CSS filters, with a fallback to a simple opacity reduction for older browsers. As a gimmick, there is a light and a dark theme for the website, the latter being the default. You can switch between themes using the sun icon in the menu. On the technical sides, both themes have their own stylesheets, compiled using the same SASS source files with different variables. Only the active theme's CSS is directly loaded on the site, the other is included as a preloaded asset. The active theme is saved in the session, so it stays active for the duration of the browser session. For our reference projects (Referenzen), we replaced the background color with the primary color of the project (each project has a color field for that purpose). We determine the luminance of the primary color programmatically to find if the color has higher contrast to black or white, and use the light or dark theme accordingly. Screenshots

RockFinder v1.1.0 now supports filters. This makes it possible to use custom access control (eg showing only certain rows on a RockGrid): https://github.com/BernhardBaumrock/RockFinder/commit/3e4daae0f283280672ab606a1eef1b16497f19fe https://github.com/BernhardBaumrock/RockFinder/blob/3e4daae0f283280672ab606a1eef1b16497f19fe/readme.md#filters--access-control Filters & Access Control You can filter the resulting rows by custom callbacks: // show only rows that have an id > 3 $finder = new RockFinder('id>0, limit=5', ['title', 'status']); $finder->filter(function($row) { return $row->id > 3; }); You can also use these filters for showing only editable pages by the current user. Be careful! This will load pages into memory and you will lose the performance benefits of RockFinder / direct SQL queries. $finder->filter(function($row) { $page = $this->wire->pages->get($row->id); return $page->editable(); }); One thing to mention is that you can apply these filters BEFORE or AFTER closures have been applied. If you apply them BEFORE executing the closures it might be a little more performant (because closures will not be executed for rows that have been removed by the filter), but you will not have access to columns that are populated via closures (like page path).

Hi @breezer, I'd love to see a forum-solution for PW, but to be honest I'd only want to pay for it if it was exactly what I need or extremely flexible. Both is very unlikely. If you want to get familiar with module development in PW this would be a great opportunity to start with. Easy and I'm quite sure it would be helpful for many of us: A favicon generator helper module: You might also want to talk to @autofahrn (forum bug again... *sucks) from this post: If you choose to develop your module open source I'd be happy to assist wherever I can to make it great ? PS: A huge challenge will be all the Frontend Markup Generation of your forum. As every site can be different in PW this makes such modules a pain to develop. I'm working on a Frontend-Theming-Module right now, that might make this a lot easier...

Hello @breezer, welcome to the PW forums, If you do a quick google search like this: https://www.google.hu/search?ei=JOnpW_G4LIG0kwWxyo7gDQ&amp;q=forum+module+site%3Aprocesswire.com%2Ftalk then you can see that there is interest in a forum module for ProcessWire, for sure. Whether you can earn "enough" by making it commercial is a different matter. Keep in mind that PW has a relatively low user base, at least compared to other more popular systems out there. Still, paying for a complex module instead of implementing it can be a great timesaver if the given module comes with proper support.

Does this work with FormBuilder?

I created a demo-installation of RockGrid/RockFinder that I want to share soon that shows several examples of RockFinder/RockGrid Here's one example that @jmartsch requested support for - a grid listing the sum of all pages that reference this page: the residents can assign a house with a single pagefield: The php file for the grid (returning the final finder's sql, that's why I post it here) looks like this: <?php namespace ProcessWire; // the base table contains all houses // https://i.imgur.com/e5bC4sA.png $houses = new RockFinder('template=house', ['title']); // then we create another table containing all residents that have a living assigned // https://i.imgur.com/zYXEVIL.png $residents = new RockFinder('template=person|cat|dog,livesin.count>0', ['title', 'livesin']); // we join both tables and get a combined table // https://i.imgur.com/TE0vEPd.png $houses->join($residents, 'resident', ['livesin' => 'id']); // then we can modify the resulting SQL to our needs // https://i.imgur.com/UgzNqDD.png $sql = $houses->getSQL(); $sql = "SELECT id, title, count(resident_id) as numresidents FROM ($sql) as tmp GROUP BY resident_livesin"; // set the data // to check everything i created a test-grid where we can filter for the house title // https://i.imgur.com/9pdlYVz.png $this->setData($sql); The screenshots of the comments are here: -- -- -- -- -- The grid in the last example called "residents" is as simple as that: <?php namespace ProcessWire; $residents = new RockFinder('template=person|cat|dog,livesin.count>0', ['title']); $residents->addField('livesin', ['title']); $this->setData($residents); As you can see this somewhat complex example can be done in only 6 lines of codes (same example as above, just without comments): $houses = new RockFinder('template=house', ['title']); $residents = new RockFinder('template=person|cat|dog,livesin.count>0', ['title', 'livesin']); $houses->join($residents, 'resident', ['livesin' => 'id']); $sql = $houses->getSQL(); $sql = "SELECT id, title, count(resident_id) as numresidents FROM ($sql) as tmp GROUP BY resident_livesin"; $this->setData($sql);

Three solutions immediately spring to mind: a) Create different comments fields for each group of pages (downsides: you have to keep other settings in sync and page queries may have to run over both fields) b) If all comments pages are at the same depth (or not too deeply nested) and each has a unique (might also be grand-) parent, you can create a field on those ancestors that holds the admin contact email and use the "field:" syntax in Admin notification email: field:parent.adminemail // or, for grandchildren field:parent.parent.adminemail You could even set multiple sources this way if the adminemail might be either on the parent or the grandparent (just make sure it isn't set on both). The comments field will only use valid emails, so if a parent or grandparent doesn't have the field (or doesn't exist), that entry will be ignored. field:parent.adminemail,field:parent.parent.adminemail c) In some scenarios, you want to send notifications to the user that created the page. In that case, you can use field:createdUser.email The big downside of that approach is that when the creator of the page is no longer available to approve comments, the createdUser field has to be changed or a different email address assigned in their profile settings (and comment notifications might get lost if nobody thinks of that). It should also be possible to populate $field->notificationEmail through a hook, but from the top of my head, I can't name a convenient method to hook into.

Try: $mail = new \PHPMailer(); The backslash at the front tells it not to use the ProcessWire namespace