Leaderboard

I've done that too complicated too many times ? $wire->addHookAfter("Pages::saveReady('template=foo,id=0')", function($event) { $event->arguments(0)->status = 1; }); Now create a new "foo" page and it will automatically be published (and also the "temp" status will be removed) ? I need that all the time for backend applications...

@Robin S - I have been using this module since it was released and always thought it was a necessary tool for inserting Hanna codes, but I just starting using some of its other features like: linked_page__pagelistselect which makes it an entirely new beast - amazing. Thanks!

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)

A new client of mine has an existing WordPress site. Because the WordPress site is so large, the client wants to migrate the site section by section into ProcessWire. So as one section in WordPress gets removed, it will be replaced by a redesigned section in ProcessWire and will keep the same urls. Can WordPress and ProcessWire coexist on same site? I'm assuming they can't coexist in the same folder on the server, but is there a way to migrate content from WordPress into ProcessWire while keeping the same urls if ProcessWire is installed in a subfolder? Once all of the WordPress content is moved into ProcessWire, then the WordPress installation will be completely removed. Looking for advice from someone who has come across the same situation.

A couple weeks ago there were a lot of ideas about page builders and different approaches in ProcessWire. Some really interesting ideas actually, and great proof of concepts as well. The conversation started moving faster than I could keep up with, and I think Teppo's summary in ProcessWire Weekly 351 is a great overview, if you haven't yet seen it. These are so great in fact, that I don't think anything I build could live up to what some of you have already built. In part because my focus is more server-side than client-side development, and I can clearly see most of these page builders are much more client-side based than I have expertise in (though would like to learn). Whereas some of you are clearly amazing client-side developers; I'm blown away by what's been built, and how quickly it happened. One struggle I have with page builders is that I don't have my own good use cases for them, with the projects that I work on. Others here (like Jonathan) already have a lot of good use cases. Clearly there are a lot of benefits. I'm fascinated and enthusiastic by all of it, but can't envision how or if I'd use such a tool in my own projects. And having experience with (and particularly close use cases for) a tool is important in hitting the right notes in building it. Likely page builder support belongs in ProcessWire in some form or another, and ProcessWire can be an excellent platform for it. But the actual page builder needs to be designed and built by the people that have expertise in the tools needed to build it, and by the people that will actually use it. I think it should be a community collaboration. For anything needed to support this on the PHP side, count me in. I don't think I've got the background to "lead" the development of the page builder, but I do think I've got plenty to contribute to it. I'd also like to continue building out existing tools like Repeater/Matrix to further support page builder type use cases. I'd like to rebuild and move the auto-save and Live Preview features from ProDrafts into the core, which should also help support some of these page builder cases. Whether these will eventually apply to the larger page-builder project, I don't know, but they'll be useful either way. What are the next steps? Who's interested in working on this? Let's keep the conversion going and move forward with it.

Hi @David Karich - thanks very much for this. I just noticed that if you uninstall and reinstall, you get an SQL error because it's trying to create a table that already exists, so either the uninstall didn't clean things up properly (if that is the intention), or the install process needs to check to see if it already exists. Also, just wondering if the AJAX approach could be reserved for sites running ProCache? Is there a need otherwise for doing it this way, rather than hooking on page render? There's a good chance I am overlooking something, but just thought I'd ask. Another thought - have you considered a way for us to easily extend this to log click events to track users viewing PDFs etc? Maybe this really doesn't belong within this module and should be kept as something we implement on a case-by-case basis?

Template: YES, Field: NO It takes permissions from the very first page find operation (that is a $pages->findIDs) and then joins all raw data from the database to those page ids.

Hey guys, thank you all for your quick response. It seems like the Plesk preview URL is the problem. After I created a DNS-record from one of my domains and used it instead of the weird Pleask-preview-url it works! I hope I can help somebody with this knowledge ? Thank you and see you soon. Mats

Vielen Dank, Bernhard! Now I've put that into my ready.php and it works great. Just one thing occurred that is Umlauts are html-encoded. I.e. when having this URL: https://domain.com/processwire/tools/ourmodule?Param1=Fünf after the login it is transformed to: https://domain.com/processwire/tools/ourmodule?Param1=F&uuml;nf which essentially looses part of the value because & of course is the URL param separator. I've tracked this down into the ProcessLogin module and it seems that this line should NOT be: if(!is_int($value)) $value = $this->wire('sanitizer')->entities($value); but rather: if(!is_int($value)) $value = rawurlencode($value); because the URL string is manually built by concatenation. After fixing this in the Core our links now work great. Thanks again for your help, Bernhard. What do we do about this bug (?) in the Core module?

Untested: $wire->addHookAfter("ProcessLogin::getBeforeLoginVars", function(HookEvent $event) { $vars = $event->return; $foo = $this->wire->input->get('foo'); $bar = $this->wire->input->get('bar'); if($foo !== null) $vars['foo'] = $this->wire->sanitizer->text($foo); if($bar !== null) $vars['bar'] = $this->wire->sanitizer->text($bar); $event->return = $vars; }); Make sure to sanitize input properly!

Thx for pushing me to learn something new ? https://github.com/processwire/processwire/blob/d8945198f4a6a60dab23bd0462e8a6285369dcb9/wire/modules/Process/ProcessLogin/ProcessLogin.module#L848-L864

Thanks @teppo - looking forward to seeing all these new features. I have another one for you ? Whenever I build a search engine I emulate Google's "search phrase" use of double quotes to effectively switch from ~= to *= Would you be willing to support something like that also?

Just released a new version of the module — here's the full changelog: ### Added - Support for Indexer actions, the first one of which adds support for rendering FormBuilder forms as part of the search index. This feature is currently considered experimental. - Option to specify custom path for front-end themes via the Advanced settings section in module config. - EditorConfig (.editorconfig) and ESLint (.eslintrc.json) config files for defining coding style for IDEs. - Support for collapsible content blocks in Debugger. ### Changed - Indexed templates option in module config is now AsmSelect, which makes it possible to organize indexed templates by preferred priority. - Query class converts lesser than and greater than to HTML entities to allow matching said entities, as well as encoded HTML markup. - All Debugger CSS classes refactored to follow `.pwse-` format. The first part of this is now built in, i.e. the indexed templates setting uses AsmSelect and the order of indexed templates gets stored. The module doesn't yet actually do anything with this information, so there's more work to be done. That'll be the focus of next release ? I'll give this more thought once I (hopefully) figure out the initial template order thing.

@bernhard Thanks for a really helpful example. It's also good to know other people are using Processwire as a full backend application. Thanks also for making RockFinder3, it's a great module. For non-editable tabular lists, I've just used the core MarkupAdminDataTable that works well enough for my needs, although I should probably build some sort of reporting module so that I can easily define group headers and footers for totals, headings etc.

thx! it's working now calling the function like this. Cool! $CssClasses = $modules->get('InputfieldPageGrid')->getCssClasses();

Both. It causes the inputfield to be rendered via renderValue() so there's no input, and even if somebody manually added an input in their browser any processing of the inputfield is prevented.

Version 2.0.0 as new master version available (PLEASE READ!) 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. >>>> All information about the changelog and bug fixings in the first post.

@teppo I appreciate your detailed response. What makes this a risky approach? @LostKobrakai I did find a way to host both WordPress and ProcessWire in the same directory: 1. I changed the WordPress index.php to index-wp.php. 2. I added the following to the ProcessWire .htaccess file (removing the WordPress .htaccess file). The directories here will use WordPress, anything else uses ProcessWire. RewriteCond %{REQUEST_URI} ^/(news|category|tag|about) RewriteRule .? index-wp.php [L] The only caveat to this is that I can't get WordPress to display as the default Home page. But maybe this is a less risky approach to using a proxy service?

Bingo! In case someone needs it: // Activity form if($page->template == 'activity') { $forms->addHookBefore('FormBuilderProcessor::renderReady', function($e) { $form = $e->arguments(0); if($form->name == 'activity_form') { $page = wire('page'); // IS THIS RIGHT? $selected = array(); // IS THIS RIGHT? $selected['selected'] = 'selected'; // IS THIS RIGHT? // Get Atividade field $inputfield = $form->getChildByName('atividade'); // Get InputfieldPage $select_field = $inputfield->getInputField(); // Get the correspondent InputfieldSelect $select_field->addOption($page->id, $page->title, $selected); // Add current page as selected option } }); $activity_form = $forms->render('activity_form'); } Thanks for your help @elabx, it made all the difference!