update AG

I was able to fix it with this hook in ready.php. It now sets the correct timestamp. $wire->addHookAfter("InputfieldDatetime::processInput", function (HookEvent $event) { $input = $event->arguments(0); if($input->get('_InputfieldForm') == 'testactivity' && $event->object->inputType == 'html') { $correctValue = strtotime($input->get($event->object->getAttribute('name'))); $event->object->setAttribute('value', $correctValue); } });

@BitPoet Somehow it always saves the values from the origin fields also for the cloned fields in the formbuilder form session when I submit the paginated form to the next page. The post request values looks good to me?

Hi Ryan, Happy (belated?) Birthday from me as well. Are you still in Atlanta or already on your new trip to the Netherlands? I'm also on a trip with my 2 kids to the states and I am right now in Atlanta, just in the neighborhood of Decatur. Maybe we can have a coffee before you take off again? Best, Oliver

@BitPoet Is this module still being maintained? We are attempting to use it for paginated Formbuilder forms, but it appears to have an issue with loading values from the session for duplicated/multiplied fields within the fieldset. Instead of retrieving the correct values for each field, it seems to take the value from the first field and apply/overwrite it to all subsequent fields.

That's even more confusing then. We have ProCache installed normally with no exceptions for pages. But even if that's the case - shouldn't then at least the homepage be bugged for page view counting? Because we don't experience any difference compared to subpages. Every page load (or reload) on the homepage is being counted on our site. At this point I'm seriously at a loss of ideas. I agree, I don't think that's the solution to our problem. I'll continue to check if there's a workaround for your issue.

We're normally using the default lifespan of 1 hour (3600s). But even after bumping this up to 604800=1 week, we don't experience any changes. I can reload the page as many times as i want - on my computer, phone, whatever - it still counts every single page view. Are you sure about this? Of course ProCache stores HTML versions of the cached page and serves these instead of re-rendering the page from PHP. But wouldn't ProCache need to access the ProcessWire API to check if ProCache is even enabled or not? If that's the case, then the MostViewed module should be loaded as well, as we're accessing the ProcessWire API at the same stage as ProCache. At the ready function of an autoload module - which is executed immediately after the ProcessWire API is ready. Or is ProCache exiting this process as soon as it realizes it has a cached page for the current request? If so, could I prioritize the order of autoloaded modules? That would currently be my only other guess... Though it's weird that it's working just fine on our end.

Interesting... I would've thought that HTMX could be an issue. We have ProCache enabled for every page, but we still get page views. When opening a private tab and clicking through our site I can see every click I made in the Dashboard. So I am genuinely confused on how it would not work on your end. When automated page view tracking is enabled, we're writing the page view inside the modules ready function. This should fire on every page load, as the module is being autoloaded. Do you see an issue here?

Hi @DV-JF Seems like we missed a line in the module config in ProcessUpdMostViewed.module. Fixed it in the most recent Commit 51ecafc. You can either download the ProcessUpdMostViewed.module file again, or add this line of code manually in the getModuleConfig function just below permissions yourself. 'permission' => self::PAGE_NAME, It'll be fixed on the next version bump. You might have to reinstall the module to get the permissions to work. I haven't figured out yet if there is somehow an option to keep the database table when uninstalling the module to not lose any data on reinstalling the module. Therefore you might want to export the table manually if you do not wish to lose page-view data. Hope that helps! Cheers

Hi @wbmnfktr sorry for the late response - I thought I clicked on "Submit Reply"... I've made some deeper monitoring on our website's traffic where we're actively using this module. We do indeed count some less views than our analytics shows us. But reading throught our modules' code I would not see an issue where actual page views won't get count. At this point I genuinely assume that the module simply filters out more crawlers than our analytics. Did you figure something out on your end in the meantime?

I'm a bit puzzled about what might have gone wrong here since your project settings appear correct. The module is also compatible with ProCache enabled, so that shouldn't be an issue. Could you please share your Module-Config so I can analyze the problem further?

It should work right away. You should see the tracked pages here: Menu "Setup" > "Most Viewed".

Hi @wbmnfktr thanks for your feedback! Here's briefly how it works with the default values of 1 day, 2 days and 3 days: Think of the 1st timerange as plan A - it fetches the 10 most viewed pages in the last 24 hours. If for whatever reason there haven't been 10 pages viewed in the past 24 hours, we then move to plan B, which is the 2nd timerange. Here, we look into the past 48 hours for page views. The 3rd timerange is plan C, in case we still need more articles to complete our list of "10 most viewed pages". So really, the 2nd and 3rd timeranges are like our safety nets to always make sure that we have a full list of 10 pages, regardless of viewer traffic. But given your site is quite crowded, it's likely that the list will be filled up within the first 24 hours, so you may not ever even need the 2nd and 3rd timeranges. Regarding the waiting time post-installation: it all depends on your timeranges. If you've set them as 1 day, 2 days, and 3 days, then ideally you'd wait for 3 days. But in practice, if your site has a good traffic volume, you may start seeing your top articles much sooner! If you adjust your first timerange to be 7 days and 8/9 days as a fallback (10080, 11520 and 12960 minutes) you'd ideally wait for 7-9 days. Does that make sense? I've tidied up the way we log events to prevent any confusion. Just to clarify: - 404 page-views don't contribute to the count and so, to avoid clutter, they've been removed from the logs, even while debugging. - another reason for removing 404 from the logs: every missing image, file, etc triggers a 404 - which can and surely will eventually be a lot. - the tracking of our module isn't affected by what PageHitCounter does, because it's triggering a 404 event that we ignore either way. I've also updated the logs to include the reason each time a page-view gets passed over. This means not only will you know which views have been tracked, but also which ones weren't tracked and exactly why. Thanks for that - I've also updated the check for crawler. I'm using the same method as PageHitCounter - this seems like a reliable approach. I have updated the GitHub Repository with the most recent changes. You can check the releases section there to see them. Alternatively, you should be able to update the module directly from the module configuration in your ProcessWire installation by clicking the link 'check for updates' right next to the module-version. Hope that helped! Cheers

Hi everyone, We have a new module for you: the UpdMostViewed module. It's an addition to your ProcessWire site that enables you to track page views and deliver a list of your most visited pages within a given time range. This data is particularly useful for creating frontend features like a "Most Read Articles of the Week" widget. Installation You can choose to: Head into your ProcessWire backend, go to Modules > New and search for the Module UpdMostViewed. Get the module directly from the latest releases on our GitHub repository. If you're using Composer for your project, you can add the module by running the command composer require update-switzerland/updmostviewed in your project root directory. Once downloaded, you can install the module via the ProcessWire admin. Configuration The UpdMostViewed module provides you with a variety of configuration options. You can exclude certain branches, specific pages, certain IPs, restrict counting to specific templates, define which user roles to count, ignore views from search engine crawlers, and more. Moreover, you can also customize the time ranges for the "most viewed" data. Links For more detailed information on usage, updates, or to download the module, please visit our GitHub repository and check out the module in the Module Directory.

Hey @FireWire Whatever you did, it's working now: Downloaded your branch, deinstalled the module first and than installed your new version. All is working fine. Configuration of the settings now all work without getting an error anymore. Great help. Thanks a lot.

You can access it directly and get a JSON response, when the path is correct: {"error":"FLUENCY_METHOD_NOT_ALLOWED","message":"Fluency API Error: Method Not Allowed"} But I didn't get anything so I looked closer to the path and saw that I had a wrong path. I had /processwire/fluency-1/api/translation/ as api-path, which was probably due that I deleted the module and reinstalled it so maybe it created this new path. I changed it now and it works. Second: Still when I try to edit the settings page in the Module I get the 503. See the attached network response. I still think it is somehow a security issue, when trying to save to the database due to all this serialized data in the POST-request. DB is by the way MySQL 8.0.