Jump to content

Recommended Posts

55 minutes ago, bernhard said:

What if I have some piece of code that is needed on several templates (controllers are out) that has some business logic?

I use Utility Classes in these cases 🙂

Or you could maybe use PHP traits and use them in the controller classes?

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Thx @Craig I did read about them and then forgot that they exist 🙂 Sounds like a good usecase for them! So I'd build a utility class "LocalTime" and then call LocalTime::local("d.m.Y H:i:s")? Sounds like a good solution!

Share this post


Link to post
Share on other sites

Something like that, yes! Use it in controllers and/or components as and when you need to 🙂 

If I needed more, or different, date or time functions than just "local()", I'd maybe call it "DateTimeHelper" and have various functions inside all related to date/time calculations or formatting, as I like to group similar things together.

I also like to use these for getting pages for sections of the site that are repeated in different places - like news or events - and have functions like findRecent() or findByCategory(), which can accept parameters for limit, category, etc. These can then be used on homepages, sidebars, main news/events pages, or RSS. The functions interpret the parameters, set some defaults (parent, template), and make some pages()->find() calls to return the requested pages.

Share this post


Link to post
Share on other sites
16 minutes ago, Craig said:

If I needed more, or different, date or time functions than just "local()", I'd maybe call it "DateTimeHelper" and have various functions inside all related to date/time calculations or formatting, as I like to group similar things together.

Yeah, but that sounds like a good usecase for a regular PW module as this could likely also be useful for other projects 🙂 

Share this post


Link to post
Share on other sites
2 hours ago, bernhard said:

that sounds like a good usecase for a regular PW module

Like RockDatetime? 😉 Yeah - if it's mostly site-specific, I'd put it in a utility class. Multiple sites - probably a module 🙂 

  • Like 1

Share this post


Link to post
Share on other sites

Heads-up! Wireframe 0.12.0 is now the latest master version. This is a pretty big update (in both lines of code, as well as features), so I'd recommend testing carefully after updating. The biggest parts are implemented as a companion module Wireframe API, but there are quite a few changes and updates for the main module as well:

### Added
- Support for named arguments when using `Wireframe::component($component_name, $args)`.
- JSON API. See comments in the WireframeAPI module file for more details.
- New Page methods Page::getController() and Page::setController().
- Module config screen provides support for creating directories corresponding to configured Wireframe URLs, assuming that they were provided as relative paths.

### Changed
- Wireframe::setView() accepts optional view name as an argument.
- View::setController() accepts Controller name (string) in addition to Controller class instance or null.
- When Controller is instantiated, it no longer overrides the Controller property of the related View instance.

### Fixed
- Wireframe::partial() now works as expected for partial names with file ext included (partial_name.php etc.)
- Wireframe::partial() prevents 2 or more dots in partial name, just in case (directory traversal is not intended).

 

  • Like 4

Share this post


Link to post
Share on other sites

@teppo just a short heads-up 🙂

I'm building my new design mostly of components. The homepage view looks like this:

<?php namespace ProcessWire;
echo Wireframe::component("Header");
echo Wireframe::component("Search");
echo Wireframe::component("Slider");
echo Wireframe::component("Welcome");
echo Wireframe::component("Visions");
echo Wireframe::component("News");
echo Wireframe::component("Quotes");
echo Wireframe::component("Newsletter");
echo Wireframe::component("Partner");
echo Wireframe::component("Footer");

This is pseudocode of the Welcome component:

<?php namespace Wireframe\Component;
class Welcome extends \Wireframe\Component {
  public function __construct() {
    $this->setBg();
    $this->setEmblem();
  }
  private function setBg() {
    $this->bg = null;
    try {
      $item = $this->wire->gg->home()->get(HomePage::field_slider)->first();
      $img = $item->get(Slideritem::field_img);
      $this->bg = $item->imgUrl($img);
    } catch (\Throwable $th) {
      $this->log($th->getMessage());
    }
  }

  private function setEmblem() {
    $this->emblem = null;
    $img = $this->wire->gg->settings()->get(HomePage::field_emblem_white);
    if(!$img) return;
    $this->emblem = "<img class='tm-emblem uk-margin-large-left' src='{$img->maxHeight(100)->url}' uk-svg>";
  }
}

While this is really not a big deal, I wonder if it would be possible to get rid of the bypass of having to set component properties manually and have them listen to getMyprop() methods automatically?

Maybe they could even do a try catch automatically and log the error silently on production and throw an exception on dev?

The component would then become a lot cleaner:

<?php namespace Wireframe\Component;
class Welcome extends \Wireframe\Component {
  
  public function getBg() {
    $item = $this->wire->gg->home()->get(HomePage::field_slider)->first();
    $img = $item->get(Slideritem::field_img);
    return $item->imgUrl($img);
  }

  public function getEmblem() {
    $img = $this->wire->gg->settings()->get(HomePage::field_emblem_white);
    if(!$img) return;
    return "<img class='tm-emblem uk-margin-large-left' src='{$img->maxHeight(100)->url}' uk-svg>";
  }
}

Thx

Share this post


Link to post
Share on other sites

Hey @bernhard!

I believe this is the same concept that was discussed earlier, i.e. having direct access to public component class methods from the component view? If so, I'll be sure to dedicate this some thought soon, and if it does indeed seem like a good idea, I'll try to get it implemented for the next release (after 0.13.0, which went live a few minutes ago) 🙂

I'm leaning towards adding this feature, but the added complexity still worries me. Just providing access to public methods of the class is one thing, but if I go on and add that, I pretty much have to add at least the (runtime) caching support currently provided by the controller to make sure that devs don't accidentally step into a really nasty performance trap. And if I add this, for the sake of consistency I have to consider also adding support for persistent caching, method aliases, disabled methods, and a few other things.

Anyway, this is just me thinking out loud. I'll see what I can do about this in the near future 🙂

I've added your idea about catching errors and logging them to my todo list. Not entirely sure about this one yet, but it's definitely worth thinking through.

  • Thanks 1

Share this post


Link to post
Share on other sites

Wireframe 0.13.0 went live a while ago.

This version introduces only one new feature: variables sent by controller to the view — as well as $partials and $placeholders — now work as-is while rendering fields (= in field templates). In previous versions these were accessible via the $view API variable, which didn't feel quite as intuitive. This required a new hook so there's a bit of added overhead, but at the same time various optimizations were made here and there, so this is unlikely to be noticeable.

One thing to note is that this version contains a few breaking changes, though I'd be a little surprised if they affected any real sites: some Wireframe methods were converted from public to protected (these were never really intended as part of the "public API"), and the first argument for Controller class constructor method is no longer an instance of ProcessWire (this wasn't actually necessary).

Here's the full changelog:

### Added
- New hook makes View properties directly accessible in TemplateFiles (e.g. when rendering field templates)

### Changed
- Wireframe::getController() is now a public method that can return current Controller instance, the Controller instance for provided page, or a Controller instance for provided Page and template name.
- Visibility of following methods was changed from public to protected: Wireframe::___checkRedirects(), Wireframe::___redirect(), Wireframe::___initView(), Wireframe::___initController(), \Wireframe\Config::getCreateDirectoriesField().
- Controller class implementation was streamlined: new objects are wired using the native wire() function, and thus Controller constructors no longer require the ProcessWire instance as an argument.
- Wireframe no longer caches partials unnecessarily, plus new Partial objects are automatically wired.
- Various minor optimizations, some code cleanup, and a few improvements to comments.

 

Share this post


Link to post
Share on other sites
57 minutes ago, teppo said:

I believe this is the same concept that was discussed earlier, i.e. having direct access to public component class methods from the component view?

Yes 🙂 Just wanted to share my experience so far and point out that I still think it would be nice to have.

1 hour ago, teppo said:

I'm leaning towards adding this feature, but the added complexity still worries me. Just providing access to public methods of the class is one thing, but if I go on and add that, I pretty much have to add at least the (runtime) caching support currently provided by the controller to make sure that devs don't accidentally step into a really nasty performance trap. And if I add this, for the sake of consistency I have to consider also adding support for persistent caching, method aliases, disabled methods, and a few other things.

No idea about the complexity behind, so of course it's better to think twice 🙂 Also no idea about Wireframes caching yet. I'll throw everything to ProCache in the end 🙂 

---

What I wondered during the last days of working with Wireframe is if all those different concepts (controllers, views, components, partials) are really necessare or make sense? I found myself rewriting some partials to components because I added some business logic. Now I have only one partial left 😄 Maybe I'll have to add others, maybe not. I don't know yet. But I wonder if it wouldn't be easier to have just one concept for all blocks? So everything would be a component and work the same. I understand that Controllers are tied to the template of the viewed page, but couldn't that also be handled by the component? I'm not sure I like that all my content is split up in different "types" and it's not instantly clear where I have to look for markup portion xy...

Maybe that feeling is even stronger because I'm using custom page classes a lot. So there's not really a need for controllers at all, because my pages are already some kind of controller?! But even if that was one part of the "problem", the other part still remains: Why partials + component? Wouldn't it be easier to merge them to one single concept that always works the same? I know, that would bring in lots of breaking changes, but I'd be interested why you built the module like that. Maybe there is a good reason for that I just didn't realize until now 🙂 

Please don't take this as criticism at all. Just trying to find the right way for doing the frontend part of my projects 🙂 

  • Like 2

Share this post


Link to post
Share on other sites
3 hours ago, bernhard said:

Why partials + component? Wouldn't it be easier to merge them to one single concept that always works the same? I know, that would bring in lots of breaking changes, but I'd be interested why you built the module like that. Maybe there is a good reason for that I just didn't realize until now 🙂 

As I get it, partials came first (there were no components at the time). And components were added later due to user requests. I think too that only one (the components)) should stay in the future. But I may be missing something.

  • Like 2

Share this post


Link to post
Share on other sites
6 hours ago, bernhard said:

Why partials + component? Wouldn't it be easier to merge them to one single concept that always works the same? I know, that would bring in lots of breaking changes, but I'd be interested why you built the module like that. Maybe there is a good reason for that I just didn't realize until now 🙂 

I'm going to start from the end, because this is the easy part (maybe) 😅

First of all, all the main concepts found from Wireframe have been around, in one form or another, for about a decade. Wireframe (the module) was developed a couple of years ago, and components were added about six months ago. Partials have been around since the very beginning, while components are a brand new thing.

As for "should there be both partials and components", this is a good question going forward:

  • Components are more versatile, but also more complex. There's a class (for business logic) and one or more views (for markup).
  • Partials are a lot simpler. Even though you can pass params to partials and arrange them in directories by type or whatever, they are essentially just individual include files.

In my typical project there's a need for both: by default I prefer the simplicity of partials, but if I really need to do something more complex on a per-element basis (justifying the mental and technical overhead of the class based approach), I go with a component instead. Heck, in one recent project I even surprised myself by using components within components. Not what I'd call an "easy to grasp setup" (which is always something that I try to emphasize in my work), but it gets the job done and was fun to work on.

Will components and partials eventually merge into one? I don't know — maybe, maybe not. For the time being I quite like having them both around. In my projects they tend to solve different problems, even though they could be used interchangeably 🙂

6 hours ago, bernhard said:

Maybe that feeling is even stronger because I'm using custom page classes a lot. So there's not really a need for controllers at all, because my pages are already some kind of controller?!

Oh, I'm sure that this makes a huge difference!

As I've mentioned before I haven't really used custom Page classes, because — for my use cases — controllers provide same benefits, and then some more. Nevertheless, had custom page classes existed when I started working on Wireframe, there's a good chance that I would've taken an entirely different route 🙂

6 hours ago, bernhard said:

What I wondered during the last days of working with Wireframe is if all those different concepts (controllers, views, components, partials) are really necessare or make sense? I found myself rewriting some partials to components because I added some business logic. Now I have only one partial left 😄 Maybe I'll have to add others, maybe not. I don't know yet. But I wonder if it wouldn't be easier to have just one concept for all blocks? So everything would be a component and work the same. I understand that Controllers are tied to the template of the viewed page, but couldn't that also be handled by the component? I'm not sure I like that all my content is split up in different "types" and it's not instantly clear where I have to look for markup portion xy...

I might've already touched some of the same topics earlier — particularly the one about having more than one type of object in Wireframe — but a few additional notes on this:

  • You don't have to use anything you don't need. Layouts, views, and controllers are all optional. In many of my projects there's one layout, a bunch of views (often much fewer than there are viewable templates, since many templates are so simple that the layout file takes care of all the markup), and a few controllers (just for those templates that require something "more complex" behind the scenes; news or event containers / lists, page search, etc.
  • The "everything is a component" approach is quite possible with Wireframe, though that was never really something I intended (or expected, to be honest!) The roots of Wireframe are in the MVC architecture, and that's where controllers, view, and model (which in this case is actually ProcessWire) come in. Components were intended as something that you can use to "fill in the gaps"; a bit like utility classes, for that matter.

When you say that "Controllers are tied to the template of the viewed page", that's actually not entirely true: by default Wireframe will indeed only know that for a Page using the "basic-page" template it should check if a controller class called BasicPageController exists... but you can also make multiple pages share a single controller, change the controller on the fly, etc. Much of this is pretty new and I'm still experimenting with it, but I have high hopes that it will become even more useful in the future.

As for the "couldn't that also be handled by the component" part: controllers do certain things that components don't, there's always exactly one controller active for a specific page at any given time, and these two work in a different context. The context of a controller is a page render request, while the context of a component is much smaller — essentially the subset of the request that it has been provided with. In my opinion it's best to keep them as separate concepts — at least for the time being — though once again who knows what will happen in the future 🤷‍♂️

6 hours ago, bernhard said:

Please don't take this as criticism at all. Just trying to find the right way for doing the frontend part of my projects 🙂 

I hope I don't really need to say this, but... feedback, comments, and (constructive) criticism is always welcome. I can't promise that I'll agree with all of it, but I'm happy to hear others' experiences nevertheless 👍😅

--

I'm pretty sure that you've seen this already, but I've got a couple of site profiles online — https://github.com/wireframe-framework/site-wireframe-docs and https://github.com/wireframe-framework/site-wireframe-boilerplate. These are a bit dated by now (neither uses components, for an example), but they may provide some insight into the way I personally use Wireframe.

I've been really looking forward to revisiting the weekly.pw website and sharing that as well, hopefully something I can get done before the end of the year. This site is also really, really dated (both visually and feature wise), and I'd also like to show off some of the new stuff in Wireframe 🙂

  • Like 4

Share this post


Link to post
Share on other sites

Changelog for Wireframe 0.14.0:

### Added
- New ComponentView class, as well as the ability for component views to access Component class public methods as properties, in the same way view files and layouts can access Controller class public methods.

### Changed
- Hook related code moved from Wireframe module to separate Hooks class.
- Accessing public class methods as properties in view files were moved into new trait MethodPropsTrait. This is used internally by Controller and Component classes.
- Some minor improvements related to dependency injection within Wireframe objects (and ProcessWire objects instantiated by Wireframe.)

@bernhard, what you suggested here...

On 8/28/2020 at 1:09 PM, bernhard said:

While this is really not a big deal, I wonder if it would be possible to get rid of the bypass of having to set component properties manually and have them listen to getMyprop() methods automatically?

... is now doable. The way it works is just like with Controllers (this functionality is provided by a new shared trait behind the scenes):

<?php
// component class
namespace Wireframe\Component;
class Test extends \Wireframe\Component {
	public function hello() {
		return 'world';
	}
}

// component view
hello <?= $this->hello ?>

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Hey @teppo,

first off thank you for creating this module - really love the approach. I recently took over a processwire project, which pretty much consisted of php/html spaghetti-code. Being an processwire greenhorn (having worked with Typo3 & WP up until now), this drove me crazy - but your module definitely helped me to bring some structure into that chaos. ^^

Anyway, long story short: 
I was wondering, if i can also use blade or twig templates for the view part of a component? It works flawlessly for all my template & partial views, but i am somehow having issues with components. Always running into something like this, although an default.blade.php view exists for that component:

Method Wireframe\Component\SocialWidget::__toString() must not throw an exception, caught InvalidArgumentException: View [SocialWidget.default] not found.

I might also just be missing something, as i only have an intermediate knowledge of php.

Thanks in advance!

  • Like 1

Share this post


Link to post
Share on other sites

@mlfct, what version of the module do you use? I recently changed a few things that might've been related, so there's a chance that it's fixed already.

That being said, I don't use twig/blade myself, so if the issue still exists in the latest version, I'll have to dig in to see what's going on.

Also, thanks! I'm really glad to hear that uou've found Wireframe useful 🙂

  • Like 1

Share this post


Link to post
Share on other sites
Quote

what version of the module do you use? I recently changed a few things that might've been related, so there's a chance that it's fixed already.

I've been using 0.14.0 from the your repo master branch and mauricius' blade renderer implementation. 

  • Like 1

Share this post


Link to post
Share on other sites

Thanks, @mlfct. This seems to be related to the WireframeRendererBlade module — I've opened an issue for it here: https://github.com/mauricius/WireframeRendererBlade/issues/1. Simply put the Blade renderer appears to expect component views to be found from /site/templates/views/[component name]/[view name].blade.php, while Wireframe expects them to be at /site/templates/components/[component name]/[view name].blade.php 🙂

I would recommend keeping tabs on that issue if you want to use Blade. Twig implementation shouldn't have the same issue, though.

  • Like 1

Share this post


Link to post
Share on other sites

@teppo was already following up on the github issue. works perfectly now - thanks for pinpointing the issue and chiming in with mauricius!

  • Like 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By David Karich
      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 Changelog
      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.0)
      > 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
    • By Robin S
      A new module that hasn't had a lot of testing yet. Please do your own testing before deploying on any production website.
      Custom Paths
      Allows any page to have a custom path/URL.
      Note: Custom Paths is incompatible with the core LanguageSupportPageNames module. I have no experience working with LanguageSupportPageNames or multi-language sites in general so I'm not in a position to work out if a fix is possible. If anyone with multi-language experience can contribute a fix it would be much appreciated!
      Screenshot

      Usage
      The module creates a field named custom_path on install. Add the custom_path field to the template of any page you want to set a custom path for. Whatever path is entered into this field determines the path and URL of the page ($page->path and $page->url). Page numbers and URL segments are supported if these are enabled for the template, and previous custom paths are managed by PagePathHistory if that module is installed.
      The custom_path field appears on the Settings tab in Page Edit by default but there is an option in the module configuration to disable this if you want to position the field among the other template fields.
      If the custom_path field is populated for a page it should be a path that is relative to the site root and that starts with a forward slash. The module prevents the same custom path being set for more than one page.
      The custom_path value takes precedence over any ProcessWire path. You can even override the Home page by setting a custom path of "/" for a page.
      It is highly recommended to set access controls on the custom_path field so that only privileged roles can edit it: superuser-only is recommended.
      It is up to the user to set and maintain suitable custom paths for any pages where the module is in use. Make sure your custom paths are compatible with ProcessWire's $config and .htaccess settings, and if you are basing the custom path on the names of parent pages you will probably want to have a strategy for updating custom paths if parent pages are renamed or moved.
      Example hooks to Pages::saveReady
      You might want to use a Pages::saveReady hook to automatically set the custom path for some pages. Below are a couple of examples.
      1. In this example the start of the custom path is fixed but the end of the path will update dynamically according to the name of the page:
      $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'my_template') { $page->custom_path = "/some-custom/path-segments/$page->name/"; } }); 2. The Custom Paths module adds a new Page::realPath method/property that can be used to get the "real" ProcessWire path to a page that might have a custom path set. In this example the custom path for news items is derived from the real ProcessWire path but a parent named "news-items" is removed:
      $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'news_item') { $page->custom_path = str_replace('/news-items/', '/', $page->realPath); } }); Caveats
      The custom paths will be used automatically for links created in CKEditor fields, but if you have the "link abstraction" option enabled for CKEditor fields (Details > Markup/HTML (Content Type) > HTML Options) then you will see notices from MarkupQA warning you that it is unable to resolve the links.
      Installation
      Install the Custom Paths module.
      Uninstallation
      The custom_path field is not automatically deleted when the module is uninstalled. You can delete it manually if the field is no longer needed.
       
      https://github.com/Toutouwai/CustomPaths
      https://modules.processwire.com/modules/custom-paths/
    • By tcnet
      PageViewStatistic for ProcessWire is a module to log page visits of the CMS. The records including some basic information like IP-address, browser, operating system, requested page and originate page. Please note that 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. There are 4 different view modes.
      View mode "Day" 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. View mode "Month" shows the total of all visitors per day from the first to the last day of the selected month. View mode "Year" shows the total of all visitors per month from the first to the last month of the selected year. View mode "Total" shows the total of all visitors per year for all recorded years. Please note that multiple visits from the same IP address within the selected period are counted as a single visitor.
      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.
      parseUserAgentStringClass
      This module uses the PHP class parseUserAgentStringClass available from: http://www.toms-world.org/blog/parseuseragentstring/. This class is required to filter out the browser type and operating system from the server request.
      Special Feature
      PageViewStatistic for ProcessWire 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 inserted 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 (-).
       
    • By MoritzLost
      This module allows you to integrate hCaptcha bot / spam protection into ProcessWire forms. hCaptcha is a great alternative to Google ReCaptcha, especially if you are in the EU and need to comply with privacy regulations.

      The development of this module is sponsored by schwarzdesign.
      The module is built as an Inputfield, allowing you to integrate it into any ProcessWire form you want. It's primarily intended for frontend forms and can be added to Form Builder forms for automatic spam protection. There's a step-by-step guide for adding the hCaptcha widget to Form Builder forms in the README, as well as instructions for API usage.
      Features
      Inputfield that displays an hCaptcha widget in ProcessWire forms. The inputfield verifies the hCaptcha response upon submission, and adds a field error if it is invalid. All hCaptcha configuration options for the widget (theme, display size etc) can be changed through the inputfield configuration, as well as programmatically. hCaptcha script options can be changed through a hook. Error messages can be translated through ProcessWire's site translations. hCaptcha secret keys and site-keys can be set for each individual inputfield or globally in your config.php. Error codes and failures are logged to help you find configuration errors. Please check the README for setup instructions.
      Links
      Github Repository and documentation InputfieldHCaptcha in the module directory Screenshots (configuration)

      Screenshots (hCaptcha widget)

       
       

       
    • By joshua
      ---
      Module Repo: https://modules.processwire.com/modules/privacy-wire/
      Github: https://github.com/blaueQuelle/privacywire/
      Module Class Name: PrivacyWire
      Changelog: https://github.com/blaueQuelle/privacywire/blob/master/Changelog.md
      ---
      This module is (yet another) way for implementing a cookie management solution.
      Of course there are several other possibilities:
      - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/
      - https://github.com/webmanufaktur/CookieManagementBanner
      - https://github.com/johannesdachsel/cookiemonster
      - https://www.oiljs.org/
      - ... and so on ...
      In this module you can configure which kind of cookie categories you want to manage:

      You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience.
      Currently there are four possible cookie groups:
      - Necessary (always enabled)
      - Functional
      - Statistics
      - Marketing
      - External Media
      All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ...
      When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax:
      <script type="text/plain" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The data-attributes (data-type and data-category) are required to get recognized by PrivacyWire. the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision.
      If you want to give the users the possibility to change their consent, you can use the following Textformatter:
      [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie.
      You can also add a custom link to output the banner again with a link / button with following class:
      <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> This module is still in development, but we already use it on several production websites.
      You find it here: PrivacyWire Git Repo
      Download as .zip
      I would love to hear your feedback 🙂
      CHANGELOG
      You can find the always up-to-date changelog file here.
×
×
  • Create New...