Jump to content

David Karich

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by David Karich

  1. @ryan you wrote a while back about modules you were working on. Unfortunately, nothing has been heard since then. Can you tell us anything new about the Snapshot and Page Language/Translation Export modules?
  2. @bernhard, I think that shouldn't be a problem. I also have other updates on the to-do list. I'll try to push it this year during my Christmas holiday. Unfortunately, I really don't have time at the moment to roll that out sooner.
  3. For the 15th anniversary of my business, I gave myself and my website a present and relaunched it. 🎉 Happy Birthday to me 🤓www.flipzoom.de

  4. Now that you mention it, the first thing that strikes me is how often I have to build endpoints like this over and over again on every project. 😵😄 I think that would be a really useful feature request, to have a fixed endpoint, which then each module can extend and have access to it.
  5. Yes, I understand. Unfortunately, this case cannot be mapped with the module, because the whole core concept is based on triggering a 404 via a non-existent endpoint and hooking in before it. I wanted to keep it simple and not have to install an additional page as API endpoint and a template for it. 🙂
  6. But this is not a problem, as long as you can define a segment in some way. I also have it in use, where segments can have any value. The segment definition via RegEx works, for example: regex:^affiliate/[a-zA-Z0-9-_]+$ For all other cases, even if I have not yet encountered one, where you can not define any segments and everything is wildcard (which you should also avoid from SEO point of view or also the potential for DDOS attacks), the module is then unfortunately not the right choice. 🙂
  7. Yes, this is the problem described. Just tested it. Forget what I said before. This error occurs only when there are missing segment definitions with segments enabled. Edit 1: Just validated it again too, there is no other way. You need to define the URL segments or leave placeholders via regex so that an endpoint can be created and there is a possibility that a 404 will be triggered. And without a segment definition a 404 will never be triggered and so the script can't hook in at that point. Edit 2: Consequently, the request is not going to the module, but simply to your page, which itself is the response in your console in debug mode. But the tracking endpoint can also not be placed uniformly on the root, because in cookie mode with differentiated URL segments the cookie must be stored only on this path. I will think about whether there should be an alternative way without AJAX. But I can't implement this adhoc, because I don't have the time for it and for this project no customer releases budgets anymore, because these use cases for which it was needed, work like this. @adrian Please define the URL segments in your project and test it, it should work with that. 🙂
  8. I think you have the PW debug mode on, right? The response is not returned when debug mode is off. Also, all non-AJAX based requests are not processed further. https://github.com/FlipZoomMedia/PageHitCounter/blob/master/PageHitCounter.module#L643 Or have I misunderstood something?
  9. Hi @adrian, unfortunately I can't reproduce the problem on any installation where I just tested it. The module does not handle the uninstall process manually either, it uses PW's native methods: https://github.com/FlipZoomMedia/PageHitCounter/blob/master/PageHitCounter.module#L1130 – There I'm confused unfortunately, why when uninstalling the field your MySQL table is not removed. Maybe local development environment with wrong rights? 🤔 Surely this would also work, but this makes it in the end, I think, unnecessarily inflated in the code. The current method does not block the rendering process because rights, templates, filters, cookies, etc. have to be checked first and then an SQL query has to be waited for before it continues (even if it is only milliseconds here). It is therefore asynchronous and does not block the frontend. It clears the way for self-created AJAX requests for tracking and it works as it is implemented, for all methods. Whether ProCache is in use or not. 🙂 The module should never become a tracking or statistics module in its concept. There are simply enough better tools that you can use for that. It has always been and should remain so, a simple way to quickly sort by interests or get an overview without big bells and whistles. Everything that is based on template, you can track with it but also. See the Custom API tracking methods. So if your downloads have a template in any form, you can also use it to map a download counter. For example, I have already mapped this with login counters. (https://github.com/FlipZoomMedia/PageHitCounter#example-tracking-a-page-hit-via-api-and-jquery) For everything else there is Analytics or Matomo, or the many other tools. But ask @bernhard, I don't want to anticipate anything, but he builds something great on the basis of the PageHitCounter. 😄
  10. Hi @Zeka, a 404 should explicitly not be triggered. This is because the AJAX request would not be valid and would return a 404 and thus an incorrect status code. In addition, I think the discussion and issue was here before on the front pages, in previous versions every hit was registered as a 404 if you installed the 404 Page Logger or other 404 monitoring tools. Which then quickly flooded the log. So the only option was to set the priority close to 0 and prevent 404s. 🙂
  11. Please see upgrade note for 2.0.0 - After the update, you need to perform a module refresh directly so that the database schema is updated.
  12. 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.
  13. Unfortunately I cannot reproduce an issue here. I have used the module in several productive multilingual environments. No matter from which language version (even for me the default is not english) it is counted. Maybe you have "URL segments" in use? I have written an info about this in the readme. A separate counter function for each language version is not planned. All hits are summed up, no matter from which language. Maybe in the future, when I have more time for it. Sorry.
  14. Honestly, I think that for this particular case, implementing a hook is a bit too much. Since you can easily access the counter value via "$page->phits" at any time, you can modify and build your labels in the PageTree yourself. In the module configurations you can simply specify the templates for which the counter will not be automatically output as a label under "Exclude templates for page tree counter". Or disable it completely if you build all your labels yourself. 🙂 Or have I missed something? 😄
  15. As requested, in version 1.2.7 the function is now public. 🙂
  16. Version Update 2.0.1 The current version has got a bug fix. Thanks to @ngrmm I could discover a bug which causes that the module cannot be loaded if the MatrixRepeater field ends with the name "repeater". The code was adjusted and information about the problem was provided. All information and downloads are updated in the first post.
  17. @ngrmm I could identify the problem in your installation and have provided a fix in version 2.0.1 The problem was that your repeater field ended with the name "repeater". I have provided more information about this in the readme. For testing I have updated version 2.0.1 on your provided test environment and now it works. 🙂
  18. Sorry @eydun, I only saw your question now. I already brought the Floating Buttons into the game in 2018 as a proof of concept. You can find the code for them here: Or directly on GitHub: https://github.com/processwire/processwire-requests/issues/177
  19. Unfortunately I cannot reproduce the problem at all. Please try the new version. Otherwise I can only imagine that the module collides with the JS code of another module. Maybe you can give me access to a test system so I can have a look at it.
  20. Version Update 2.0.0 The current version has got some improvements, bug fixes and new features. Many thanks to @Autofahrn, who created the idea and code base for copying multiple items at once! Amazing feature! Also, there is now the option to disable the copy and paste dialogs. Last but not least, thanks to @joshua, for suggesting a bug-fix in context with normal repeater fields. All information and downloads are updated in the first post.
  21. By the way, here's a filter I often use to enrich the path for files or images directly with the corresponding pageID, so that you only have to prefix the file path. <?php namespace RockFinder3Column; /** * Column type for multi-value fields like options, page reference, etc */ class FileWithID extends \RockFinder3\Column { public function applyTo($finder) { $finder->query->leftjoin("`{$this->table}` AS `{$this->tableAlias}` ON `{$this->tableAlias}`.`pages_id` = `pages`.`id`"); $finder->query->select("GROUP_CONCAT(CONCAT(`{$this->tableAlias}`.`pages_id`, '/', `{$this->tableAlias}`.`data`) ORDER BY `{$this->tableAlias}`.`sort` SEPARATOR ',') AS `{$this->alias}`"); } } This results in the string for example: "1234/myfile.jpg" and now just prepend with "$config->urls->files" in the output and you have the full path to the file. Maybe it helps somebody and is looking for exactly that. 🙂
  22. On the one hand, I was more or less forced to switch to RF3 because RF2 no longer worked with the new PW-Master 3.0.164. Somehow the bindValues in the selectors were not processed correctly anymore, so that no PageIDs and paths were resolved correctly in the SQL statement. For this reason I have migrated completely to RF3. That was not a big problem either. In general, not much has changed from the public functions. In addition, it is also much more comfortable in RF3 to create and manage your own filters. Well done! I also wrote my own table aliases in the SQLs in RF2 quick and dirty, which RF3 now handles very cleanly itself. My application case has not changed. I continue to use RF3 to load masses of fieldset pages within repeater items, which contain lots of fields with design options for the repeater item. As already described in the RF2 thread below: In this context, once again many thanks for this module and the further development! 🙏
  23. @bernhard, RF3 works like a charm and rock solid! After RF2 I can only thank you again for the clean code and documentation for RF3! 🙏🍻
  24. Hey @OllieMackJames thank you, also for the donation. I think it came from you? 🍻 I'm not able to reproduce the problem with the prompt. Does the DeveloperConsole give you any JS Errors? I had tried to implement the multiselect function before. But I failed on some points because it was not stable and reliable and in the end there were too many dirty JS hacks. Originally, this module was just a proof of concept, with the hope that @ryan would implement this function cleanly into the core of RepeaterMatrix. The needs for this feature are already quite high for the users.
  25. I can only thank @bernhard again for this module and for the support he provided, for example in finding a solution for option fields. RockFinder2 can not only be used to load masses of pages faster, it can also be used at field level. For example, I used it to load about 40 to 60 fields per repeater matrix type, which are also further nested in FieldsetPages (for design settings) in one query. This amount of fields caused 700 or more single SQL queries to be executed and up to 140 PW-Page objects to be loaded into RAM. This caused a significant loading delay. By using RockFinder2 the SQL queries could be reduced to 200 on average. About 60 page objects less are loaded in RAM, the CPU is also happy and the loading time for pages without cache was also reduced on average to 700 ms to 1 second. Good job Bernhard! 🙏
  • Create New...