Leaderboard
Popular Content
Showing content with the highest reputation on 08/22/2020 in all areas
-
Page View Statistic for ProcessWire is a module to log page views of the CMS. The records including some basic information like IP-address, browser, operating system, requested page and originate page. This module doesn't claim to be the best or most accurate. Advantages One of the biggest advantage is that this module doesn't require any external service like Google Analytics or similar. You don't have to modify your templates either. There is also no Javascript or image required. Disadvantages There is only one disadvantage. This module doesn't record visits if the browser loads the page from its browser cache. To prevent the browser from loading the page from its cache, add the following meta tags to the header of your page: <meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" /> <meta http-equiv="Pragma" content="no-cache" /> <meta http-equiv="Expires" content="0" /> How to use The records can be accessed via the Setup-menu of the CMS backend. The first dropdown control changes the view mode. Detailed records View mode "Detailed records" shows all visits of the selected day individually with IP-address, browser, operating system, requested page and originate page. Click the update button to see new added records. Cached visitor records View modes other than "Detailed records" are cached visitor counts. Cached visitor records are collected on a daily basis from the detailed records. This approach is new in version 1.0.8 and ensures fast display even with many records. Another advantage is that the detailed records can be deleted while the cache remains. The cache can be updated manually or automatically in a specified time period. Multiple visits from the same IP address on the same day are counted as a single visitor. Upgrade from older versions Cached visitor counts is new in version 1.0.8. If you just upgraded from an older version you might expire a delay or even an error 500 if you display cached visitor counts. The reason for this is that the cache has to be created from the records. This can take longer if your database contains many records. Sometimes it might hit the maximally execution time. Don't be worry about that and keep reloading the page until the cache is completely created. Upgrades in general It seems that the upgrade function don't get called after an upgrade. This might be a bug in ProcessWire. This can lead to an error message ("Unknown column...") if you try to open the statistic page immediately after an upgrade. There are two ways to avoid this error message. Click the "Continue to module settings" button directly after the upgrade or open the Modules page and click the "Refresh" button. Time of view This module can record the time a visitor viewed the page. This feature is deactivated by default. To activate open the module configuration page and activate "Record view time". If activated you will find a new column (S.) in the records which means the time of view in seconds. With every page request, a Javascript code is added directly after the <body> tag. Every time the visitor switches to another tab or closes the tab, this script reports the number of seconds the tab was visible. The initial page request is recorded only as a hyphen (-). Execution time Starting with version 1.1.9 this module records the PHP execution time from the initialization of the module till the HTML output in seconds. Settings You can access the module settings by clicking the Configuration button at the bottom of the records page. The settings page is also available in the menu: Modules->Configure->ProcessPageViewStat. IP2Location This module uses the IP2Location database from: http://www.ip2location.com. This database is required to obtain the country from the IP address. IP2Location updates this database at the begin of every month. The settings of ProcessPageViewStat offers the ability to automatically download the database monthly. Please note, that automatically download will not work if your webspace doesn't allow allow_url_fopen. Dragscroll This module uses DragScroll, a JavaScript available from: http://github.com/asvd/dragscroll. Dragscroll adds the ability in view mode "Day" to drag the records horizontally with the mouse pointer. PhpUserAgent This module uses PhpUserAgent available from: https://github.com/donatj/PhpUserAgent. PhpUserAgent is required to filter out the browser type and platform from the server request. New in version 1.1.0 A new feature in version 1.1.0 offers the possibility to record user names of logged in visitors. Just activate "Record user names" and "Record loggedin user" in the module settings. New in version 1.1.3 A new feature in version 1.1.3 offers an internal WHOIS function. In the module settings you can switch between internal and external WHOIS. New in version 1.1.4 Detailed records can now be exported as CSV-file. The file contains all data of the specified date regardless of the pagination. The button is located at the bottom of the page. New in version 1.1.8 The UserAgentParser was exchanged with PhpUserAgent due to some complaints.6 points
-
Hello and Thank You! Of course I've some screenshots. I wasn't sure if these screenshots were appropriate to show here. I've made IP addresses unrecognizable.
5 points -
Relative to version 3.0.164, this latest version on the master and dev branch (3.0.165) contains 16 commits with various minor fixes, improvements and optimizations, and it resolves 6 reported issues. Version 3.0.164 has been very stable, and this version should be even more so. Both the dev branch and master branch are identical at this moment. As mentioned last week, new versions of both FormBuilder and ProCache are in development, and I’ve been working on both of them quite a bit this week. I mentioned some of the updates being made in FormBuilder last week. Another new feature to mention is the addition of reCAPTCHA to the spam prevention tools. While our built in honeypot is just as effective (when setup properly), it does its work silently, behind the scenes, never visible to anyone. Whereas reCAPTCHA is hard to miss, which is a benefit for clients that want to to be able to literally see spam prevention measures in place. No doubt, it brings a certain level of comfort, and adds another level of authority to your forms. So I’m really glad to add it to our set of form tools. Rather than building it into the form “actions” I’ve instead built it as an Inputfield module (InputfieldFormBuilderRecaptcha), as this gives you a little more flexibility with regard to placement and customization. It is ready for download now in the FormBuilder board Download thread (login required). It can be used with any version of FormBuilder 0.3.9 or newer; meaning it’s ready to use now. If you download it, be sure to read the pinned reCAPTCHA thread in there for detailed instructions (it's very easy to setup). I’ve been talking about it for a long time, but it seems like it may finally be a good time to re-do the modules.processwire.com site. It all works just fine, but just needs an update, consistent with the rest of processwire.com. So we’ll likely slow the pace of core updates for 2-3 weeks to work on that, sometime between now and the end of the year. Thanks for reading and have a great weekend!4 points
-
Like RockDatetime? ? Yeah - if it's mostly site-specific, I'd put it in a utility class. Multiple sites - probably a module ?1 point
-
While you're at this, perhaps you could take a look at this as well: https://github.com/processwire/processwire-issues/issues/988. I haven't checked recently, but at least back then the modules directory wasn't updating the module version (note that this was unlikely to be caused by normal delay, as the version number hadn't updated in months). Thanks ? Just in case I've been updating the version numbers for all my modules manually. It's not a huge deal, but would be better if the automation worked (though again, I haven't done any tests recently, so maybe this was already fixed.)1 point
-
I use Utility Classes in these cases ? Or you could maybe use PHP traits and use them in the controller classes?1 point
-
Totally agree and please don't forget to validate all my requests before implementing (as you already do) ? I'm just throwing in ideas and questions as they arise. What would really be great would be some kind of illustration of the process that one has to go through when adding content to a site (layout). As you said: Decisions, decisions ? They should be made as simple as possible ? built with https://www.yworks.com/products/yed (free and all major platforms); Of course this is totally simplified and missing other decisions that have to be made, like "could it be reused in other projects? --> build a module" Hm. One thing that made me really curious about wireframe was this: Thx for the clarification! This feels like a quite big limitation for me. What if I have some piece of code that is needed on several templates (controllers are out) that has some business logic? Should I create a pw module for that? I think that's often too much overhead (you need to install it, define moduleinfo stuff etc). Imho there should be an easy way to handle such situations. Components sound great, but accessing methods should also be easy. I've now tried this: <?php namespace Wireframe\Component; class Slider extends \Wireframe\Component { public function __construct() { $this->component = $this; } public function foo() { return "foo!"; } } <p class='uk-container'>I am a slider! <?= $component->foo() ?></p> I am a slider! foo! Ok, that would be a quite easy solution. I'm wondering 2 things though: Couldn't (shouldn't) that or something like that happen automatically? Just like it's done in controller view files? Shouldn't Controllers and Components work the same with the only difference that one is applied automatically to the loaded template and the other one has to be loaded manually via Wireframe::component('foo') ? Or are there any other important differences that I'm missing? --- Thx for all your efforts on this!! ? Looking forward ?1 point
-
Currently the component view file has no way to access the component class. Instead the component class has to pass all the required variables to the view. View can obviously perform actions that seem sensible in that context (such as formatting a date). I have considered adding access to component methods but wasn't entirely sure if it was a good idea. This is still on my todo list and I'll give it more thought in the near future, likely after 0.12.0 has been released. On one hand it might be handy (and in line with how controllers/views behave), but on the other hand every new feature introduced to the module increases complexity, so I want to make sure that it also provides substantial value. Decisions, decisions ? Your current options would be to a) pass the variable formatted from the controller class to the vie file — and if individual instances of this component could require different formats, then passing the format as a parameter is indeed a sensible approach — or b) handle formatting in the component view file (and again optionally pass the format as a parameter to the component and from there to the view file). -- I'll have to get back to some of your other points — which were really good, by the way! — later ?1 point
-
I didn´t mean to say which approach is better. I think RockMigrations is a good tool. SolidWire is not a replacement of any migration strategy or tool. It's just an idea to ease the communication and prototyping between developers and other people. It's in the same area of https://plantuml.com/ Just a tool to improving an eagle view of the system. The JSON output is just an idea similar to https://doc.mapeditor.org/en/stable/manual/introduction/ Any other proper migration tool could use it to generate a proper output. But is not mandatory :).1 point
-
I know from a trusted source that some of you use Laragon as their prefered Windows DEV solution. Due to a recent conversation I noticed that there might be a nice little feature some of you may not know about. Laragon offers the Quick app option with some tools already predefined. In order to have ProcessWire there as well you just have to add one (two with a comment) line to your Laragon configuration. # ProcessWire ProcessWire=composer create-project processwire/processwire %s Just in case you want to start your next project a little bit faster.
1 point
