Jump to content

JSON structure with direct access to key


Recommended Posts

Hey folks,

for a module (a pagebuilder based on PageTable) I need to save some settings as JSON. The values are saved for each page table item (a pw page). It's working well, but I am looking for ways to improve the structure I have. As I'm not that experienced with JSON, maybe someone more experienced can take a look and tell me if my approach is good practice. 

My goal is to make all the items accessible by page id, without looping over them (using objects instead of arrays):

// access from template with pw page var
$jsonObject->items->{$page}->cssClass;

Her is an example of my JSON structure:

{
  "items": {
    "3252": {
      "id": "3252",
      "cssClass": "pgrid-main",
      "breakpoints": {
        "base": {
          "css": {
            "grid-column-end": "auto",
            "grid-row-end": "auto",
            "grid-column-start": "auto",
            "grid-row-start": "auto",
            "align-self": "auto",
            "z-index": "auto",
            "padding-left": "60px",
            "padding-right": "60px",
            "padding-top": "60px",
            "padding-bottom": "60px",
            "background-color": "rgb(255, 255, 255)",
            "color": "rgb(0, 0, 0)"
          },
          "size": "@media (min-width: 576px)",
          "name": "base"
        }
      }
    },
    "3686": {
      "id": "3686",
      "cssClass": "test_global",
      "breakpoints": {
        "base": {
          "css": {
            "grid-column-end": "-1",
            "grid-row-end": "span 1",
            "grid-column-start": "1",
            "grid-row-start": "auto",
            "align-self": "auto",
            "z-index": "auto",
            "padding-left": "0px",
            "padding-right": "0px",
            "padding-top": "0px",
            "padding-bottom": "0px",
            "background-color": "rgba(0, 0, 0, 0)",
            "color": "rgb(0, 0, 0)"
          },
          "size": "@media (min-width: 576px)",
          "name": "base"
        }
      }
    },
    "3687": {
      "id": "3687",
      "cssClass": "block_editor-3687",
      "breakpoints": {
        "base": {
          "css": {
            "grid-column-end": "span 2",
            "grid-row-end": "span 1",
            "grid-column-start": "auto",
            "grid-row-start": "auto",
            "align-self": "auto",
            "z-index": "auto",
            "padding-left": "0px",
            "padding-right": "0px",
            "padding-top": "0px",
            "padding-bottom": "0px",
            "background-color": "rgba(0, 0, 0, 0)",
            "color": "rgb(0, 0, 0)"
          },
          "size": "@media (min-width: 576px)",
          "name": "base"
        }
      }
    },
    "3696": {
      "id": "3696",
      "cssClass": "block_editor-3696",
      "breakpoints": {
        "base": {
          "css": {
            "grid-column-end": "span 2",
            "grid-row-end": "span 1",
            "grid-column-start": "auto",
            "grid-row-start": "auto",
            "align-self": "auto",
            "z-index": "auto",
            "padding-left": "0px",
            "padding-right": "0px",
            "padding-top": "0px",
            "padding-bottom": "0px",
            "background-color": "rgba(0, 0, 0, 0)",
            "color": "rgb(0, 0, 0)"
          },
          "size": "@media (min-width: 576px)",
          "name": "base"
        }
      }
    }
  },
  "breakpointActive": "base",
  "breakpointActiveSize": "@media (min-width: 576px)"
}

 

Link to post
Share on other sites

 @ukyo Thanks! Your module looks great! However I already have a way to build my JSON based on inputfields, wich is just needed to save some internal css of my module. All the real content is saved in the database with regular pw fields. I would like to keep it that way, but was looking to get some feedback on my JSON structure. Specially I'm not sure if it's valid to have numerical keys (page id)? Everything is working fine, so if it's not bad practise for some reason, I will just keep it that way.
 
Doing it all in JSON (including the content) with your module would have the benefit of being able to transfer the templates to other installations without importing the database and also have it version controlled, right? But the downside is that it's not searchable as well as native fields and also that not all fields are supported?
 

Link to post
Share on other sites

I have builder system with PageTable input field,403366945_EkranResmi2021-02-1118_05_03.thumb.png.8096e1b2386cc436515063dae0893644.png

Text field is InputfieldText Field (Searchable)

Properties field is Mystique Field (Limited search support)

581196593_EkranResmi2021-02-1118_08_40.thumb.png.41109564644bdc5d9c5cec3c8e60f625.png

Current Mystique field version support search limited. Working with next version on my side and it will support searching.

  • Like 1
Link to post
Share on other sites

@jploch You're mixing up storage and public API, which is not a good idea. JSON is a storage / transport format, it's always a string which contains a serialization of data. The purpose of JSON is to store or transmit data in different formats between systems – like your database, your server and the client's browser. JSON is also language-independent – you can decode a JSON-string in JavaScript and in PHP. But as soon as you do that, the result is that language's default representation of that JSON string. For PHP, this means you get either a stdClass object or arrays (depending on the flags you give to json_decode).

So you need to ask two different questions: What is the best way to store my data, and what is the best way to present it to a user of your module?

Data representation

Of course you can just json_decode the JSON string and pass the result to the user of your module. But that's a bad idea:

  • You have zero guarantees regarding the structure of your data. You won't notice if your data is missing a specific field, some field is an integer instead of a string, your items are indexed by page name instead of key or whatever else. This will cause errors that are very hard to track down.
  • The user has no indication how your data is structured – to figure that out, I will either have to refer to the documentation for everything or have to dump stdClass objects and figure things out from there ...
  • You can't have nice things like code completion, proper IDE support etc.

Instead, you want to parse that unstructured data into a representation (usually, a set of classes) that guarantees a specific structure and has a proper public API for access and modification of the data. Using proper objects with type-hinting will also allow you to find any errors in the structure and abort the process at parse time with an appropriate error message (see Parse, don't validate for an in-depth explanation). For example, to represent your data, you might use classes like PageBuilderEntry and PageBuilderItem to represent a list of items with meta data (the breakpoint fields, in your example) and individual items, respectively. The you can provide utility methods for different use cases – for example, methods to get a list of items indexed by key or by any other field.

If you want to build closer to ProcessWire, you can also use a class that extends WireArray to represent a list of items, this will give you many helpful methods (like getting an item by key) out of the box. For the items themselves, you might just reuse the page itself (if the IDs correspond to 'real' pages in your system) or extend the Page class.

Data storage

Separating the representation from the storage makes the specific structure you store your data in less important, since only your module will interact with it. Just build a static helper method to build the appropriate representation based on a JSON string (e.g. PageBuilderEntry::fromJSON) and a method to encode that representation back to JSON (PageBuilderEntry::toJSON). The fromJSON method is responsible for parsing the data and throwing the appropriate error when it's not in the expected format.

That said, personally I usually prefer regular arrays instead of maps for storage, because it's easier to parse and massage into different formats. But again, it depends on how you want to represent the data.

  • Like 8
Link to post
Share on other sites

@MoritzLost Thanks for your explanation! Helps me to understand this a little bit better.

2 hours ago, MoritzLost said:

Of course you can just json_decode the JSON string and pass the result to the user of your module. But that's a bad idea:

Iam not sure the data will ever be relevant to the user, for now I just use the JSON internally (creating JSON with js and decoding it with PHP). What I meant with "using objects instead of arrays" here is just how I decode the JSON in php: json_decode($jsonString) instead of (json_decode($jsonString, true). This gives me easy access to the items (which are just pages, so I thought it would be nice to be able to access them by page id like the pw api works). To be able to do this I also need to create the JSON structure like in the example above (with JS). Hope that makes sense. Not sure if the cons you listed matter that much in this case. I will think about it.

2 hours ago, MoritzLost said:

If you want to build closer to ProcessWire, you can also use a class that extends WireArray to represent a list of items, this will give you many helpful methods (like getting an item by key) out of the box. For the items themselves, you might just reuse the page itself (if the IDs correspond to 'real' pages in your system) or extend the Page class.

This sounds interesting. Maybe you can provide an example how to extend WireArray?

 

Link to post
Share on other sites

here is another possible structure

{
  "items": [{
    "id": "3252",
    "cssClass": "pgrid-main",
    "breakpoints": {
      "base": {
        "css": {
          "grid-column-end": "auto",
          "grid-row-end": "auto",
          "grid-column-start": "auto",
          "grid-row-start": "auto",
          "align-self": "auto",
          "z-index": "auto",
          "padding-left": "60px",
          "padding-right": "60px",
          "padding-top": "60px",
          "padding-bottom": "60px",
          "background-color": "rgb(255, 255, 255)",
          "color": "rgb(0, 0, 0)"
        },
        "size": "@media (min-width: 576px)",
        "name": "base"
      }
    }
  }, {
    "id": "3686",
    "cssClass": "test_global",
    "breakpoints": {
      "base": {
        "css": {
          "grid-column-end": "-1",
          "grid-row-end": "span 1",
          "grid-column-start": "1",
          "grid-row-start": "auto",
          "align-self": "auto",
          "z-index": "auto",
          "padding-left": "0px",
          "padding-right": "0px",
          "padding-top": "0px",
          "padding-bottom": "0px",
          "background-color": "rgba(0, 0, 0, 0)",
          "color": "rgb(0, 0, 0)"
        },
        "size": "@media (min-width: 576px)",
        "name": "base"
      }
    }
  }, {
    "id": "3687",
    "cssClass": "block_editor-3687",
    "breakpoints": {
      "base": {
        "css": {
          "grid-column-end": "span 5",
          "grid-row-end": "span 2",
          "grid-column-start": "2",
          "grid-row-start": "2",
          "align-self": "auto",
          "z-index": "98",
          "padding-left": "0px",
          "padding-right": "0px",
          "padding-top": "0px",
          "padding-bottom": "0px",
          "background-color": "rgb(255, 204, 204)",
          "color": "rgb(0, 0, 0)"
        },
        "size": "@media (min-width: 576px)",
        "name": "base"
      }
    }
  }, {
    "id": "3696",
    "cssClass": "block_editor-3696",
    "breakpoints": {
      "base": {
        "css": {
          "grid-column-end": "span 2",
          "grid-row-end": "span 1",
          "grid-column-start": "auto",
          "grid-row-start": "auto",
          "align-self": "auto",
          "z-index": "auto",
          "padding-left": "0px",
          "padding-right": "0px",
          "padding-top": "0px",
          "padding-bottom": "0px",
          "background-color": "rgba(0, 0, 0, 0)",
          "color": "rgb(0, 0, 0)"
        },
        "size": "@media (min-width: 576px)",
        "name": "base"
      }
    }
  }],
  "breakpointActive": "base",
  "breakpointActiveSize": "@media (min-width: 576px)"
}


 

Link to post
Share on other sites
Quote

Iam not sure the data will ever be relevant to the user, for now I just use the JSON internally (creating JSON with js and decoding it with PHP).

Then the user is your own module. All the points in my post above still apply – your module has to make some assumptions about the structure of the JSON data. Even if the data is only consumed internally, passing unstructred data around can cause unexpected errors at any point. So it's still better to parse the data into a representation that makes guarantees a specific data structure, and raise errors during parsing (as opposed to a random error anywhere in your module's lifecycle that's hard to track down). Also, will your module not allow customization through, for example, custom page builder elements or hooks? As soon as that's the case, developers using your module will have to use your data, so it should provide a uniform interface to accessing that data.

Quote

This sounds interesting. Maybe you can provide an example how to extend WireArray?

Basically, any ProcessWire class representing some sort of collection, so you can check out those. For example, check out Pagefiles, FieldsArray and PageArray which all extend WireArray. See how they make use of all the utility methods WireArray provides and override just the methods they need to customize to adapt the WireArray to a specific type of data? For example, check out FieldsArray::isValidKey only allows Field objects to be added to it, so adding anything else will immediately throw an error. You can use this to map your pagebuilder items to a specific class and then have a class like PageBuilderItems extending WireArray that only accepts this class as items. This will go a long way towards having a uniform data structure.

Quote

What I meant with "using objects instead of arrays" here is just how I decode the JSON in php: json_decode($jsonString) instead of (json_decode($jsonString, true). This gives me easy access to the items (which are just pages, so I thought it would be nice to be able to access them by page id like the pw api works).

Again, don't mix up storage and representation. For storage, I would prefer the second example you posted, with items being an array instead of a map and the ID being just a regular property. Simply because arrays are more convenient to create, parse and map (in JS especially, but also in PHP). Though again, it doesn't matter as soon as you parse the data. The representation your module (or others, see above) uses to access the data can provide utility methods, like accessing an item by key.

Regarding the last point specifically, WireArray can help you with this. The documentation is kind of handwaivy about how WireArrays handle item keys – WireArray::add doesn't take the key as an argument, but WireArray::get allows you to get an item by key, so where does the key come from? If you check the source code, turns out WireArray automatically infers a key based on the item – see WireArray::getItemKey. Your custom class can extend this to use the ID property of a given item as the key. For example, FieldsArray::getItemKey does exactly this. This allows you to use page IDs to access items without having to store your data specifically as a map. On top of that, you can use all the other utility methods WireArray provides to access elements in the any way you like.

  • Like 4
Link to post
Share on other sites

@MoritzLost Thank you for the detailed answer! I'm still at a very beginner level with php, all I know about it, I basically learned from using PW and it's api. Doing mainly frontend development, this is the first bigger module I'm building. So I'm still new to how classes work. Now that I have another look at it, what you sad makes a lot of sense. I will try to implement the class approach with my own utility methods.

I will also have a look at WireArray, this seems like a nice solution.
Thanks again for your help. I might come back at you if I hit another roadblock.

  • Like 1
Link to post
Share on other sites

I'm still a little lost on how to implement my JSON decode method and use WireArray as a representation of my data.
My module builds a dynamic stylesheet, based on the JSON file. This dynamic stylesheet is just a php file that the user can include in his/her main template file. The JSON is saved in one field, that live on the page holding all the PageTable items.

Since I need the CSS to be rendered  in the backend and frontend and I wanted to give the user more freedom on where to include the CSS I thought this is a good approach. Not sure if it's really clever to have this in a separate file instead of my module file. 

This is my working code I have in the dynamic stylesheet file:

<style>
<?php 
namespace ProcessWire; 
$backend = 0; 
$p = $this->page;

if($isAdmin = $this->page->rootParent->id == 2) {
$p = $this->pages->get((int) wire('input')->get('id'));
$backend = 1; 
}

$css='';
$settingsArrayPage=json_decode($p->pgrid_settings);

  if( !(empty($settingsArrayPage))) {

       foreach($settingsArrayPage->items as $item) { 
           
           foreach($item->breakpoints as $breakpoint) { 
             
             if ($backend) {
               $css.='.breakpoint-'. $breakpoint->name . ' ';
             } else {
               $css .= $breakpoint->size . '{ ';
             }
            
            $css .= '.' . $item->cssClass. '{ ';
          foreach($breakpoint->css as $style=> $val) {
                   $css .= $style . ': ' . $val . '; ';
               }
             
           $css .= ' } ';
             if (!$backend) {
           $css .= ' } ';
             }
         }
            
       }
  
  echo $css;
    }
 ?>

</style>

First of all where would you put the WireArray code? Is it better to have this in my module file or in the dynamic stylesheet file?
Here is my code so far.

 class PageGridData extends WireArray {
    
   public function getItemKey($item) {
// here I would place the JSON decode method from above and return the items?
		return $item->id;
	}
    
    }

Sorry this is a bit outside of my comfortzone 🙂

Link to post
Share on other sites

@jploch Ok, so currently you have a procedural approach, which is fine for a fixed use-case. My proposed solution might be overkill for what you're trying to achieve. And it will definitely be more work - and maybe the more general application for your module (which I don't even know the scope or precise purpose of) that I'm imagining isn't even what you're trying to achieve. So before you start refactoring, consider if it will actually be of benefit to your module! And of course, if you have to use code that you don't fully understand the purpose of, it won't help you in the end. If what you have is working fine for your use-case, maybe you don't need all that stuff. So just take my approach with a grain of salt 🙂

I would start by creating classes that represent the building blocks of your page builder. That would probably include a class that represents a list of CSS rules (that can use WireArray), a class for individual items (with a reference to a list of CSS rules) and a class for a list of items (this again can use WireArray). Decoding JSON would probably be the responsibility of the latter. Though of course you can also go with a more eleborate approach to transforming JSON to classes like the builder pattern.

Here's a start (I wrote this in the browser, so it will need some polish and might include some errors, but hopefully it communicates the idea behind it):

// this class represents a list of CSS rules, as included in your JSON data
class PageGridCSS extends WireArray {
	/** This class gets methods to set, get and remove CSS rules, and render them to CSS. */
}

class PageGridItem {
	// PHP 7.4+, for older PHP versions use a protected property with getters and setters
	public int $id;

	// each item holds a reference to a set of rules
	public PageGridCSS $cssRules;

	/** This class gets properties and methods corresponding to the data it represents */
}


class PageGridData extends WireArray {
    // guarantee that this can only hold PageGridItem objects
    public isValidItem ($item) {
        return $item instanceof PageGridItem;
    }

    // make PageGridItems accessible by their ID
    public function getItemKey($item) {
        return $item->id;
    }

    // convert json to the appropriate classes
    public static fromJSON (string $json): PageGridData {
        $items = json_deocde($data)['items'];
        $dataList = new self();
        foreach ($items as $item) {
            $dataItem = new PageGridItem();
			$dataItem->id = $item->id;
			/** Add all the properties to the item, catching missing or malformed data */
            $dataList->add($dataItem);
        }
        return $dataList;
    }

    public renderCSS() {
        // render the CSS for the items this instance contains
    }
}

Why even do all this? Currently, your dynamic template makes a couple of assumptions that I, as a user of your module, may not agree with. For example:

  • It always includes style tags. What if I want to save the output in a CSS file and serve it statically?
  • You infer the context (backend / frontend) which doesn't always work reliably. I also can think of some reasons why I would like to get the code for the frontend in the backend - for example, to save it to a field.
  • Your ".breakpoint-{...}" classes may interfere with my own stylesheets, so I could use a way to rename them.
  • Maybe I want only a part of the stylesheet, like the rules for a specific breakpoint.
  • ...

Making all this modular and giving users access to the functionality through a well-defined API with utility methods allows me to customize all this and access the parts that I want to use, changing those that I need to.

Though again, maybe I'm totally wrong regarding the intent and scope of your module. This way a fun exercise to think through anyway, hopefully it will be helpful to you or others looking for something similar 🙂 Hm, maybe that stuff would make a good article for processwire.dev ... 🙃

  • Like 1
Link to post
Share on other sites

@MoritzLost Thanks again! This seems to be the best way to handle it. I will further investigate if it complicates my current setup too much. But I get the benefits now. Hopefully this will help others too. 

I'm generally ok with making some assumptions in my case, because you can change the CSS stuff inside the backend for each item (and the breakpoints you want) anyway, also its easy enough to overwrite some css rules with plane css/scss. Maybe I provide some api options and helper functions along the way, so this is definitely helpful. Here is a preview of the module I'm developing to give you a little more context:

 

  • Like 1
Link to post
Share on other sites

One more question to finally understand php classes a little bit better:
If I have this simple class:

class PageGridCSS {

    public $cssClasses = 'test classes';

    public function getCssClasses() {
        return $this->cssClasses;
    }
}

How can I call the function getCssClasses from outside the file it is declared in?
So far I was able  to call it from within the same file only by doing this:

$PageGridCSS = new PageGridCSS();
$PageGridCSS->getCssClasses();

 

Link to post
Share on other sites

You need a reference to the instance, so the $PageGridCSS variable in your case. That's because there can be different instances of the same class with different states and holding different data. So yes, if you create a new instance in a specific context, only that context has access to the variable. If you want to pass it around, you need to provide utility methods or pass specific instances of a class as parameters. Usually, the instances of a set of classes are linked together by properties referencing each other. For example, in my example code above, the PageGridData contains a list of PageGridItem instances, which can be accessed by key or iterated over using the utility methods provided by WireArray. Each PageGridItem then has a reference to the PageGridCSS instance belonging to it (that's the $cssRules property in my example code). For example:

function doStuff(PageGridData $data) {
	$key = 1234;
	// $item will be an instance of PageGridItem
	$item = $data->get($key);
	// $cssRules will be an instance of PageGridCSS
	$cssRules = $item->cssRules;
	// ...
}

Does that help? The best way to pass around data depends on the application flow. For ProcessWire modules, the main module class will usually have helper methods to access specific classes of the module. For example, my module TrelloWire contains a separate class (ProcessWire\TrelloWire\TrelloWireAPI) that handles all requests to the Trello API. The main module file has a utility method to get an instance of that class with the API key and token configured in the module settings. Another example is the TrelloWireCard class, which holds all the data used to create a Trello card through the API. This one is also a module, so you can access it using $modules->get() to get an empty instance. But the main module class also has a utility method to create an instance populated with data from a regular page and the module configuration. This method is used by the module internally, but can be hooked to overwrite specific fields or used to build your own application or business logic on top of the module.

  • Like 1
Link to post
Share on other sites

thx! it's working now calling the function like this. Cool!  

$CssClasses = $modules->get('InputfieldPageGrid')->getCssClasses();

 

  • Like 2
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 monollonom
      (once again I was surprised to see a work of mine pop up in the newsletter, this time without even listing the module on PW modules website 😅. Thx @teppo !)
      Github: https://github.com/romaincazier/FieldtypeQRCode
      Modules directory: https://processwire.com/modules/fieldtype-qrcode/
      This is a simple module I made so a client could quickly grab a QR Code of the page's url in the admin.
      There's not much to it for now, but if need be you can output anything using a hook:
      $wire->addHookAfter("FieldtypeQRCode::getQRText", function($event) { $event->return = "Your custom text"; }) You can also output the QR code on your front-end by calling the field:
      echo $page->qr_code_field; The module uses the PHP library QR Code Generator by Kazuhiko Arase. When looking for a way to generate a QR Code in PW I came across @ryan's integration in his TFA module. I'm not very familiar with fieldtype/inputfield module development so I blindly followed @bernhard (great) tutorial and his BaseFieldtypeRuntime. At some point I'll take a deeper look to make a module on my own.
      Some ideas for improvements :
      add the ability to choose what to ouput : page's url / editUrl / file(s) / image(s) / ... allow to output multiple QR codes ?
    • By Chris Bennett
      https://github.com/chrisbennett-Bene/AdminThemeTweaker
      Inspired by @bernhard's excellent work on the new customisable LESS CSS getting rolled into the core soon, I thought I would offer up the module for beta testing, if it is of interest to anyone.

      It takes a different approach to admin styling, basically using the Cascade part of CSS to over-ride default UiKit values.
      Values are stored in ModuleConfig Module creates a separate AdminThemeTweaker Folder at root, so it can link to AdminThemeTweaker.php as CSS AdminThemeTweaker.php reads the module values, constructs the CSS variables then includes the CSS framework Can be switched on and off with a click. Uninstall removes everything, thanks to bernhard's wonderful remove dir & contents function.
      It won't touch your core. It won't care if stuff is upgraded. You won't need to compile anything and you don't need to touch CSS unless you want to.

      It won't do much at all apart from read some values from your module config, work out the right CSS variables to use (auto contrast based on selected backgrounds) and throw it on your screen.
      You can configure a lot of stuff, leave it as it comes (dark and curvy), change two main colors (background and content background) or delve deep to configure custom margins, height of mastheads, and all manner of silly stuff I never use.

      Have been developing it for somewhere around 2 years now. It has been (and will continue to be) constantly tweaked over that time, as I click on something and find something else to do.
      That said, it is pretty solid and has been in constant use as my sole Admin styling option for all of those 2 years.

      If nothing else, it would be great if it can provide any assistance to @bernhard or other contributor's who may be looking to solve some of the quirkier UiKit behavior.
      Has (in my opinion) more robust and predictable handling of hidden Inputfields, data-colwidths and showIf wrappers.
      I am very keen to help out with that stuff in any way I can, though LESS (and any css frameworks/tools basically) are not my go.
      I love CSS variables and banging-rocks-together, no-dependency CSS you can write with notepad.



       

    • By opalepatrick
      I see old posts saying that repeaters are not the way to go in Custom Process Modules. If that is the case, when using forms (as I am trying to do) how would one tackle things like repeat contact fields where there can be multiple requirements for contact details with different parameters? (Like point of contact, director, etc) or even telephone numbers that have different uses?
      Just for background I am creating a process module that allows me to create types of financial applications in the admin area (no need to publish any of this, pure admin) that require a lot of personal or company information.
      Maybe I am thinking about this incorrectly?
    • By HMCB
      I ran across a reference to IftRunner module. The post was 6 years ago. I cant find it in available modules. Has it been pulled?
    • 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.

      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 which will be collected on a daily basis from the detailed records. This procedure ensures a faster display even with a large number of data 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 worry about that and keep reloading the page until the cache is completely created.
      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 (-).

      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.
×
×
  • Create New...