Jump to content

David Karich

Members
  • Posts

    141
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by David Karich

  1. ProcessWire InputfieldRepeaterMatrixDuplicate Thanks to the great ProModule "RepeaterMatrix" I have the possibility to create complex repeater items. With it I have created a quite powerful page builder. Many different content modules, with many more possible design options. The RepeaterMatrix module supports the cloning of items, but only within the same page. Now I often have the case that very design-intensive pages and items are created. If you want to use a content module on a different page (e.g. in the same design), you have to rebuild each item manually every time. This module extends the commercial ProModule "RepeaterMatrix" by the function to duplicate repeater items from one page to another page. The condition is that the target field is the same matrix field from which the item is duplicated. This module is currently understood as proof of concept. There are a few limitations that need to be considered. The intention of the module is that this functionality is integrated into the core of RepeaterMatrix and does not require an extra module. Check out the screencast What the module can do Duplicate multible repeater items from one page to another No matter how complex the item is Full support for file and image fields Multilingual support Support of Min and Max settings Live synchronization of clipboard between multiple browser tabs. Copy an item and simply switch the browser tab to the target page and you will immediately see the past button Support of multiple RepeaterMatrix fields on one page Configurable which roles and fields are excluded Configurable dialogs for copy and paste Duplicated items are automatically pasted to the end of the target field and set to hidden status so that changes are not directly published Automatic clipboard update when other items are picked Automatically removes old clipboard data if it is not pasted within 6 hours Delete clipboard itself by clicking the selected item again Benefit: unbelievably fast workflow and content replication What the module can't do Before an item can be duplicated in its current version, the source page must be saved. This means that if you make changes to an item and copy this, the old saved state will be duplicated Dynamic loading is currently not possible. Means no AJAX. When pasting, the target page is saved completely No support for nested repeater items. Currently only first level items can be duplicated. Means a repeater field in a repeater field cannot be duplicated. Workaround: simply duplicate the parent item Dynamic reloading and adding of repeater items cannot be registered. Several interfaces and events from the core are missing. The initialization occurs only once after the page load event Attention, please note! Nested repeaters cannot be supported technically. Therefore a check is made to prevent this. However, a nested repeater can only be detected if the field name ends for example with "_repeater1234". For example, if your MatrixRepeater field is named like this: "content_repeater" or "content_repeater123", this field is identified as nested and the module does not load. In version 2.0.1 the identification has been changed so that a field ending with the name repeater is only detected as nested if at least a two-digit number sequence follows. But to avoid this problem completely, make sure that your repeater matrix field does NOT end with the name "repeater". Changelog 2.0.1 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 2.0.0 Feature: Copy multiple items at once! The fundament for copying multiple items was created by @Autofahrn - THX! Feature: Optionally you can disable the copy and/or paste dialog Bug fix: A fix suggestion when additional and normal repeater fields are present was contributed by @joshua - THX! 1.0.4 Bug fix: Various bug fixes and improvements in live synchronization Bug fix: Items are no longer inserted when the normal save button is clicked. Only when the past button is explicitly clicked Feature: Support of multiple repeater fields in one page Feature: Support of repeater Min/Max settings Feature: Configurable roles and fields Enhancement: Improved clipboard management Enhancement: Documentation improvement Enhancement: Corrected few typos #1 1.0.3 Feature: Live synchronization Enhancement: Load the module only in the backend Enhancement: Documentation improvement 1.0.2 Bug fix: Various bug fixes and improvements in JS functions Enhancement: Documentation improvement Enhancement: Corrected few typos 1.0.1 Bug fix: Various bug fixes and improvements in the duplication process 1.0.0 Initial release Support this module If this module is useful for you, I am very thankful for your small donation: Donate 5,- Euro (via PayPal – or an amount of your choice. Thank you!) Download this module (Version 2.0.1) > Github: https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDuplicate > PW module directory: https://modules.processwire.com/modules/inputfield-repeater-matrix-duplicate/ > Old stable version (1.0.4): https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDuplicate/releases/tag/1.0.4
  2. Hi @loukote, yes that's right. The tracking and counting of PageViews also works with any form of cache. Because a small Javascript is injected, which tracks the view asnychronously, past the cache, without affecting the cache.
  3. Version 1.2.3 as new master version available All information about the changelog and bug fixings in the first post.
  4. The problem is fixed in the current version 1.2.3. Thanks for the report.
  5. Thanks for the report. This is because your pages or templates don't end with a slash. I will add it as a bug. 👍 The "/phcv1" is the request endpoint over which the AJAX requests pass to trigger a counter. In your case the URL should actually be "/produkte/phcv1".
  6. Now also available in the ProcessWire Module directory for direct installation via ProcessWire: https://modules.processwire.com/modules/page-hit-counter/ 🙂
  7. Version 1.2.2 as new master version available In version 1.2.2 a new option was introduced which allows to send page hits to templates which are not directly viewable or cannot be tracked automatically. This allows you to implement tracking that best fits your environment. An example with jQuery can be found in the first post.
  8. Info: All new features and download link will be updated in the first post.
  9. In version 1.2.1 (Master) it is now possible. Every trackable template has a field called "phits". You can use this field in selectors. Either to sort: template=news, sort=-phits or as a value selector, for example: template=news, phits>=100 For an output in the frontend, simply access the field with: $page->phits This makes it very easy to output "trending topics", for example. Select news with a date field in a certain period and sort by "phits".
  10. This problem has now been fixed in version 1.2.1 (master). Thanks for the report. All in version 1.2.1 (Master) You can now set the session lifetime to 0, which will disable cookies and count each page view Thanks for the bug report, the problem with location.pathname is fixed The problem was in fact the ctype test. Good found, thanks and fixed I have optimized the request a bit, the overhead is reduced I've added an option that lets you hide the counters. By accessing the field "phits" you can make your own output according to your ideas This is correct, only counters are reset which already have a value greater than 0. I have formulated this differently in the descriptions and in the output to make it clearer and more understandable Thanks to @matjazp and @wbmnfktr for testing and reporting. 👌
  11. Do I understand this correctly: A counter is displayed and tracked for your homepage template even though you have not configured the template? Or do you use a template for your homepage which is also used for other pages? Also a quick update: Version 1.2.0 with Sortable selector Version 1.2.0 is now available on the Dev-Branch, which makes it possible to sort the pages by hits. Please check the upgrade for test environments first, because the DB structure will be changed. Previously tracked data will be taken over, a new fieldtype will be installed. Simply replace all files and trigger a module refresh in the PW. Infos and download: https://github.com/FlipZoomMedia/PageHitCounter/tree/dev
  12. Good suggestions. 👌 Both functionalities are implemented in the current Dev branch. You can test them here: https://github.com/FlipZoomMedia/PageHitCounter/tree/dev
  13. I was just considering this approach, but it did not meet the requirements in my case. It should be live data, due to quick reactions at hot topics of the editors. And since some templates of the page in the ProCache have lifetimes of more than a week or more, an update of pages with a daily CronJob would also delete the cache unnecessarily. But as you already say, many approaches for very special requirements. 🙂
  14. Thank you. Not yet, because the data is stored in an extra table. But I will write the possibility for a future version on the ToDo-List. 🙂
  15. 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)
  16. @adrian I have no more problems with the upgrade module under PHP 7.0 and 7.1. However, I had a problem with PHP 7.2 some time ago. However, I can' t remember the exact error message. It was something with "Can't parse JSON from Github". Had then switched back to PHP 7.1 and it worked. I'm trying to reproduce that again.
  17. The cloning is in the scrolling event, because PW also clones the buttons at the page load (for the head area). If I clone the original savebuttons during pageload, they will also be duplicated in the head. However, it is ensured that this event is only executed once during scrolling as soon as the top threshold is reached. If a page is not long enough, no button needs to be cloned. The position storage is also intercepted with a debounce. The position is not saved until 250 milliseconds after the end of the scrolling event. It may look like this in the code, but any manipulation of the DOM is done only once.
  18. I have opened a ticket on GitHub, in which I present a modification respectively a proof of concept, which significantly improves the editing of pages, especially with long contents. The save buttons are always in view with this modification, and the scroll position when editing and saving is saved and restored after saving. You can also find a screencast and code extensions on GitHub. What do you think of that? Link: https://github.com/processwire/processwire-requests/issues/177
  19. After a long back and forth and many tests, the problem persists. But it could break down on a module. Ryan's update module. The Web server only hangs up when this module is called. After consulting the system administrator, he assured me that the server-side configuration is absolutely identical to the PHP 7.0 configuration. All modules, settings, paths, timeouts (60 seconds) are absolutely the same. Also the right PHP handlers are used. Only the PHP module "ioncubeloader" is not yet available for 7.1, is, according to my knowledge, but not required. However, there is no useful information in the PHP log. I'm pretty much on the hose and do not get the problem solved. Without the update module, everything runs smoothly. Does anyone have any idea what the problem is?
  20. Hm, okay. Thanks for your feedback. Then I have to go into detail in the search. Actually, I used the same configuration as PHP7. The error occurred only since I have cleared the cache of ProCache and then went to the upgrade module. Since then, the error has occurred.
  21. Hi, I have changed today a productive site with a PW installation in version 3.0.37 on PHP 7.1. Unfortunately, the system does not seem to run anymore. The page loads and loads and loads until the timeout (both: frontend and backend). The following error is only logged in the Error Log: - Premature end of script headers: index.php, referer: https://www.höhle-der-löwen.com/ - 9563#0: *21784 upstream timed out (110: Connection timed out) while reading response header from upstream - 9563#0: *21901 upstream prematurely closed connection while reading response header from upstream Does anybody have the same Problem? With PHP 7.0, everything runs smoothly.
  22. I have found a strange bug in Jumplinks module, whereby entries can not be edited. I have opened a ticket on Github, with video and solution. https://github.com/rockettpw/jumplinks/issues/11
  23. Damn it. You were faster. I had the same module on my to-do. Thanks for the module. Very helpful! I have three more points as a feature on my idea list: empty the ProCache and AIOM+ cache when they are installed. Remove all image variations and a short-cut to clear everything at once.
  24. CloudFlare helps us additionally in the defense against DDoS attacks. We have a few projects of customers who like to be the focus of attackers and often attempt to paralyze the servers. With CloudFlare, we have this blocked quickly. The service blocks the attacks, but leaves the real visitors through.
×
×
  • Create New...