Leaderboard

ProcessWire Dashboard Download You can find the latest release on Github. Documentation Check out the documentation to get started. This is where you'll find information about included panel types and configuration options. Custom Panels The goal was to make it simple to create custom panels. The easiest way to do that is to use the panel type template and have it render a file in your templates folder. This might be enough for 80% of all use cases. For anything more complex (FormBuilder submissions? Comments? Live chat?), you can add new panel types by creating modules that extend the DashboardPanel base class. Check out the documentation on custom panels or take a look at the HelloWorld panel to get started. I'm happy to merge any user-created modules into the main repo if they might be useful to more than a few people. Roadmap Panel types Google Analytics Draft At a glance / Page counter 404s Layout options Render multiple tabs per panel Chart panel load chart data from JS file (currently passed as PHP array)

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)

@tpr @adrian I have just made a (very dirty) "proof of concept" change to the code so that in the render hook it checks if the view file (e.g. views/template.latte) exists, and if not then returns to the normal render function as it would for admin templates etc. This way, any template that does not have a .latte view file will be run as normal "vanilla" ProcessWire templates. This might be handy in a lot of other situations too (and could theoretically remove the need for excluded templates and the logic to test if we are trying to render the admin template etc.). Could make for easier porting of an existing site - only running the latte code for templates that have been migrated, leaving the rest of the site running as-is. Are there any major downsides to this (other than my messy copy/pasted code)? The code is in this commit: https://github.com/porl/TemplateLatteReplace/commit/63ff03059a5278806d5525a1bb8f10fb8e9b3cf1 but I didn't want to do a pull request as it is definitely not the most elegant method of doing this check - just copied a chunk of code from your render latte string function) and there is already my pull request open for allowing for no default layout files. Let me know what you think - it certainly solved the Tracy console issue at least

During a recent maintenance routine we found that our website's database (1,700+ pages) had thousands of instances of unnecessary, garbage code that had come with copied text from Word. Passages with margins expressed in points, cms and inches, and some that were wrapped in upwards of 7 spans were among the most easily identified crimes. Purging all of this dropped our database size by over 4%. A few of the code examples above nuke all inline styles, which will impact some important out-of-the-box functionality for PW3 and CkEditor (depending on your use); specifically with many of the options with tables and lists, such as setting a column width or changing the bullet styles within a nested list. To work around that, I made some changes to Ryan's code to target specific tags and to eliminate spans (which you can only add via Source view without pasting them in). $wire->addHookAfter('InputfieldCKEditor::processInput', function($event) { $inputfield = $event->object; $value = $inputfield->attr('value'); if ((strpos($value, 'style=') === false) && (strpos($value, '<span>') === false)) return; $count = 0; $qty = 0; // Optional remove spans $value = preg_replace('/<span.*?>/i', '', $value, -1, $qty); $value = preg_replace('/<\/span.*?>/i', '', $value, -1); $count = $count + $qty; // Remove inline styles from specified tags $tags = array('p','h2','h3','h4','li'); foreach ($tags as $tag){ $value = preg_replace('/(<'.$tag.'[^>]*) style=("[^"]+"|\'[^\']+\')([^>]*>)/i', '$1$3', $value, -1, $qty); $count = $count + $qty; } if(!$count) return; $inputfield->attr('value', $value); $inputfield->trackChange('value'); $inputfield->warning("Stripped $count style attribute(s) from field $inputfield->name"); });

Easiest thing to do is to add some custom CSS to admin.css, e.g. body[class*="editor"] #notices { display: none; } that would hide all notifications for role "editor". Or some variation thereof, e.g. body[class*="editor"] #notices .NoticeDebug { display: none !important; } body[class*="editor"] #notices .NoticeMessage { display: none !important; } The cleanest way would be if this core module would have an in-built permission, then you could handle it normally via the PW access system.

Update: Menu Builder 0.2.7 Changelog Added the property extra_fields for use with getMenuItems() ONLY. This enables returning the page field values for some selected Fieldtypes. For example, the description field in the page corresponding to the menu item. Thanks @e0f for the inspiration. Full documentation of this new feature is available here. Menus in multi-lingual sites can now be called using their multi-lingual titles or names irrespective of the current user's language. For example, a multi-lingual site with English, German and Finnish languages could have a menu with the respective titles My Awesome Menu / Mein Tolles Menü / Oma Mahtava Valikko. Any of these titles can be used in the code to call the menu (using render() or getMenuItems() methods). [PS: blame you-know-who for these language translations :-)] Changed the way new menus are added. Only one menu can be added at a time. The title field/input is multi-lingual ready. See screens below. Improved the backend GUI when viewing locked menus. Only the menu items and and exit button are shown in such cases. Fixed bug that allowed access to unpublished menus for frontend rendering. Updated the documentation Refactored code to improve efficiency. In dev branch only for testing. Screenshots a. Add Menu (Multi-lingual) b. Edit Menu (Multi-lingual) c. Locked Menu d. An example usage of extra_fields (I am no designer, so yeah, nothing much to see here...but you get the idea :-)) Thanks for testing!

Yep, multi-language will require to use PW fields (at least to keep things simple). So I’ll stay with installing a cart template and a cart page where admins could add their custom cart fields. In the first version, I’ll solve this with a textarea field where the custom field config can be stored as is.

Thanks @Robin S - lazy of me to not check the settings for that. Thank you!

Yeah, sorry about that - the Tracy core just uses PHP's mail() and I wasn't sure how to hook into the send process so I could implement wireMail - of course it turned out to be easy, but it wasn't documented so had to dig a little.

Attempt to log in via the LoginRegister module several times in short period of time using an incorrect password.

Hi everybody, just came up with an idea of a new concept how we could develop our processwire pages... As some of you might know I've developed this module to skin your backend fast and easily: Why? Because several things are a lot quicker and easier to achieve in the backend then rebuilding such admin-tasks in the frontend: User login, profile editing, data presentation with access control. For example, right now I'm building a kind of dashboard for a client where users can book slots for therapies, manage their profile and data etc. This is all done in the backend and users get access after registration. So far, so good... I really like this concept, because modules are clean and especially reusable. There is a standard for how we develop things in the backend. Everything works the same, on every project, on every installation, from any developer. Today I thought: Wouldn't it be great to have those benefits also for several FRONTEND things? Or, in other words, for several parts that need to be available for PUBLIC users (guests)? For example, we could build a shopping cart checkout easily with the tools we already have in the backend. There are several hosted shopping-cart services where you get a hostet checkout-page that does also look a little different than the website's frontend, so I think this would not be a problem for certain tasks (https://foxy-demo.foxycart.com/checkout) The only problem is, that the user would have to register before it could use those tools. So I thought: Is there a possibility to make some areas of the backend available to the public? Is this a good idea at all? Or are we opening security holes there? Isn't FormBuilder doing something similar with the iframe-embed method? This is just an early stage idea, but I'd be happy to hear your thoughts on this. As much as I like ProcessWire, I don't like that I have to build lots of things for the frontend over and over again...

Hi @bernhard, I did some experimentation with an alternative idea for viewing Process modules on the frontend. I put together a proof-of-concept module you might like to check out: https://github.com/Toutouwai/ProcessFrontendAdminPage Process Frontend Admin Page A demonstration of how a Process module could execute on the frontend. This is just a proof-of-concept. Usage Install the ProcessFrontendAdminPage module. Create a new role named "frontend-only". Give this role the "process-frontend-admin-page" permission and no other permissions. Create a new user named "frontend-only" and give them the "frontend-only" role. View the "Demo frontend admin page" on the frontend while not logged into the PW admin. How the module works On install the module creates a "Demo frontend admin page" under Home. This page uses the admin template with the ProcessFrontendAdminPage process assigned. When this page is viewed by a guest they are silently logged as the "frontend-only" user. This allows them to see the rendered output of the Process module. The header and footer of the admin theme are not rendered when the page is viewed. When a user logged into the "frontend-only" account accesses any other page they are logged out. This is for the sake of logged-out users of other roles, so that when they go to log into the PW admin they don't find themselves already logged in as the "frontend-only" user. Taking the concept further You could embed the ProcessFrontendAdminPage output in an iframe on another page, to preserve a global header/footer and avoid conflicts with the admin CSS. You could add extra markup, Javascript and CSS to the ProcessFrontendAdminPage output to make it look more like the rest of your site. You could create additional executeSomething() methods to render different output depending on URL segment. You could create additional pages within your site that use the admin template and assign the ProcessFrontendAdminPage process. I think you would have to use API code to do this. Then in the execute() method you could check the name of the page being viewed and render different output accordingly.

OK, I'm back in the office and can share some more thoughts. Thx for your input so far. I'm talking about "no authentication whatsoever", yes. But I'm not talking about "free-for-all-editing". Of course I don't want to have public access to all my pages, that would be nonsense. But I was wondering if it could make sense to have some tools of the backend available to the public. ProcessModules are one example. Forms could be another. I'll explain the idea by examples: Shopping Cart Have you ever developed a shopping cart for one of your clients? It's not that easy, right? You have to take care of data storage (cookies or localstorage or session), you have to take care of the user interface (adding items, removing them, changing amounts etc), you have to make sure everything is safe (sanitization, csrf etc) and so on. This is a lot of work to do and we all know that our website's frontends are all different, so building this for one client would mean that you have to build a lot of this functionality over and over again for the next client. The alternate approach: What if we could build backend modules (process modules) and grant access to guest users? We could build a shopping cart module, that handles all these complicated things for us and uses built in tools, such as csrf, inputfields, routing ( executeFoo(), executeBar() ). It could have expiration features based on the session time. It could make it easy to register new user accounts. It could be And the best: It would be reusable! That's a huge benefit and could make developing several tools so much more efficient and fun (and maintainable). Also think of forms in general. They are always a pain, because they need field validation (front + backend), need to remember their state on failure etc.; This is all already there in the backend! It's just hidden behind a login and I wondered if it couldn't be a huge possibility to bring certain parts of those great featureset to the public. Similar to FormBuilder, as I already stated. Another example: Think of a kind of photo-book service. Users could visit your site, start building their photobook, upload pictures etc.; Just to try things out. It would be great to give those features to your users without any signup process and create the account afterwards. Eg. during checkout.; Or what about a theatre booking service? Display a seatmap, book tickets, show prices, etc: All a LOT to do in the frontend. If we developed a backend-oriented module where we can change colors of links, masthead etc, this would make things so much easier and it would be one click for the next project!! I hope you get my point. Until now, I didn't really think of developing such things in the backend, because I thought it would be a lot more effort to style the backend to my needs than building a new custom frontend solution. But that's totally wrong! It's now really just changing some color codes in LESS when using RockSkinUikit module. These pages could even be loaded in an iframe in the frontend. The height of this iframe could be adjusted via javascript, so the user wouldn't even see that he is actually in the backend. Tools are already there: It's just displaying the admin page with ?modal=1 GET parameter. While thinking of this approach new ideas and possibilities keep popping up in my head: We could build a forum software. It could be a set of process modules, using CKEditor, image upload etc. - but of course only EDITABLE for logged in users. But the thing is: The process-modules (read-only) part would need to be visible also for guests. Building a forum software with ProcessWire as it is (or better to say: as we use it) now, would be a pain, because every installation of PW has a different backend. Moving all parts that can (and should!) be standardized to the backend would be a logical step IMHO. Well... while writing I had another idea: Maybe it would be possible to create a new user + role for such modules, like "public-backend". When a website visitor add's a product to the shopping cart, he could be automatically logged in as user "public-backend". This user could then have access to the process modules that handle all the shopping cart features. We already have the demo-mode of the backend, so I think it should be possible in general to bring non-registered users into the backend. What do you think? Sorry, ideas and visions are quite hard to explain in another language. Did I make things clearer? ?

I would rather explore the other ways FormBuilder can be used, i.e. without iframes. In a nutshell, PW probably somehow loads all the necessary GUI assets (JS/CSS) from wire/modules/ so you can use them in your frontend. Theoretically, you could create a new role and a corresponding user having that role, and "silently" log in each new visitor as that user, giving him all the necessary backend rights for the task at hand. But the whole concept you're envisioning is quite blurry to me, to be honest. What happens to "real" logged-in users? What data (pages?) are they actually editing/manipulating? Where is this data stored, and how do you keep track of "which user actually edited recordset x?" Perhaps you should rather think about low-entry-barrier ways to use your web-app, such as SSO - i.e. don't discard a login entirely, but make sure that login is as painless as possible?

I've run into this problem on a client site before. I was never able to duplicate it myself, but noticed there were style attributes ending up in the CKE field of my client's site somehow, and the client said they pasted from Word. I don't have Word, and I'm not observing the issue occurring with pasting from anything else, so there must be some Microsoft trickery going on, who knows. I don't understand why CKE's ACF allows it. It does seem like a CKE bug. I'm sure it's possible to configure HTML Purifier to remove that stuff, but haven't looked too closely into it. While there is a way to force CKE to paste as plain text (see thread that flydev linked), I don't really like losing links and normal CKE formatting when I paste, because I'm often pasting from one CKE field to another, and having to redo all the formatting is a pain. Usually if I want to paste as plain text, I just use SHIFT-CMD-V on Mac (SHIFT-CTRL-V on PC), as this is a pretty universal way to paste as plain text, anywhere. But the reality is, clients aren't likely to remember it, and many are doing Edit > Paste, rather than using the keyboard. I'd rather not have the client have to think about whether they need to use plain text pasting or not. A simple way to remove style attributes from CKE fields is to hook after the process input, look for them, and then remove them. This hook at the top of your /site/templates/admin.php file should do the trick: $wire->addHookAfter('InputfieldCKEditor::processInput', function($event) { $inputfield = $event->object; $value = $inputfield->attr('value'); if(strpos($value, 'style=') === false) return; $qty = 0; $value = preg_replace('/\bstyle=(["\'])([^\1]+?)\1/i', '', $value, -1, $qty); if(!$qty) return; $inputfield->attr('value', $value); $inputfield->trackChange('value'); $inputfield->warning("Stripped $qty style attribute(s) from field $inputfield->name"); }); Word may be adding some other weirdness too, but I don't have a good example to look at to know what else there might be (MSO-specific class names?). In any case, we could probably remove it in a similar manner.