Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by wbmnfktr

  1. I personally would always create pages instead of repeater items.

    Pages can become almost everything later on as repeaters are more or less part of a page and a little more difficult to handle.

    A while back I created something to manage course bookings. Every booking ended as a single page in the backend. From there on the client was able to generate confirmation-, contract- and invoice-PDFs. Doing that with repeaters in a page might work in some kind but will end in way more work/hassle.

    Creating log entries is always a good idea as well. Kind of fallback.

    • Like 1
  2. I made it work with PHP 5.x just by changing one line.

    SubscribeToMailchimp.module - Line 23 - before:

    public function subscribe(string $email, array $data = [], string $list = "") {

    SubscribeToMailchimp.module - Line 23 - after:

    public function subscribe( $email,  $data = [],  $list = "") {

    This works without any problems so far.

    • Like 3
  3. My config.php file says:

    * Installer: Unix timestamp of date/time installed
    * This is used to detect which when certain behaviors must be backwards compatible.
    * Please leave this value as-is.
    $config->installed = 1507160150;


    • Like 3
  4. 43 minutes ago, szabesz said:

    Plain old email (client app) is not GDPR compliant... Client cannot ask you to extract certain data from the db (for analyzing it in excel for example) when they want you to send that data to them in an email because that way of handling data is out of any sort of trackable procedure, so things like asking for all personal data removal will be impossible if fragments of that data can be found all over in various data storage of various software (logs, emails, backups, xls, etc...). Clients cannot just replace their IT infrastructure and habits overnight, it will take decades of software rewriting to get to the level of GRPR and such....

    I do not know what will be the outcome of these new laws when they happen to be really forced on us but I'm not optimistic at all.

    Ok, that is GDPR-related but in another field. At least it's nothing I came across in the last couple of years. So I don't care much about this part.

    But to be honest... regulation of this exact type of irresponsible behaviour and reckless data-sharing is absolutely necessary. 

    GDPR isn't that new and data privacy is a main topic for almost a decade here in Germany.

    Let's face the truth... companies like the one in your example are the reason for things like GDPR.

    • Like 1
  5. I'm not talking about all kinds of third party software. Just a few.

    We may have to stop ourselves and our clients from using third party things like:

    • Google Analytics
    • Google Adsense
    • Google Fonts
    • Typekit and similar services
    • Ad networks
    • Facebook Pixel
    • Hotjar
    • Hubspot
    • Social Widgets
    • Free CDNs
    • ... and so on

    At least as we used it in the past.

    There are GDPR compliant ways of using Analytics, Retargeting, Monetizing and whatever. But it's work now.

    • Like 1
  6. Making sites GDPR compliant... this is a thing I'm careful with.

    Knowing what to for each client because of an audit or a lawyer who looked into it will work. No doubt. You do what a professional and reliable source said to make a site compliant.

    But I personally have not and will not tell a client what to do or what not to do. I know some things (probably more than any client and some "experts" out there) but stating and offering GDPR compliant sites can get me into trouble. I'm not a lawyer I can't offer legal advise at all.

    The without warranty-thing that eRecht24 does is fine. They offer generators and therefore legal texts based on your input. 
    Asking a lawyer (or better lawyers) to check and create everything for you will cost you a lot of money but then you will get a warranty too.

    Providing design works, logic and functionality will almost stay the same. Being GDPR compliant from start can and will be tricky.

    At some point someone has to ask a lawyer.
    At some point you have to stop implementing third parties.
    At some point other GDPR-related things kick in (like the Datenschutzbeauftragter) and the developer isn't the right person for that detail anymore.

    As developers we can't handle every aspect of the GDPR and things that will come.


    But yes... getting our hands dirty will come and it's necessary. Necessary for good and trusted developers.

    • Like 1
  7. 27 minutes ago, pwired said:

    Can we still make websites without the EU hunting us down ?

    Building a website is not the problem. Running a business with it can become the problem.

    Collecting e-mail addresses, tracking visitors and monitoring visitor-behaviour, combining it with 3rd parties like Facebook and ad networks will be a much bigger thing now.

    Cookie permissions here, double-opt-in there, and so on... it will be much more challenging than before. 


    Don't know anything special about sources in Spain, UK, US but here in Germany there are some lawyers offering (free and paid) help for all kinds of businesses.

    Just to name two I prefer: https://www.e-recht24.de/ and https://drschwenke.de/

    And as always with legal stuff: lawyers are my one and only trusted source.

    Not other companies (like the one above) that offer checklists, guides and tutorials. 

    • Like 5
  8. @ryan provides exactly this kind of TOC/jumplinks as an example for the Hanna Code module.

    Take a look at the end of the page: http://modules.processwire.com/modules/process-hanna-code/

    So you could use Hanna Code inside your pages or create something new from that example.

    Here is the code:

    // $for defines the headlines you want to take care of.
    // i.e.: h2, h3, h4
    $for = str_replace(',', ' ', $for);
    $for = explode(' ', $for);
    foreach($for as $k => $v) $for[$k] = trim($v);
    $for = implode('|', $for);
    $anchors = array(); 
    $value = $hanna->value; 
    if(preg_match_all('{<(' . $for . ')[^>]*>(.+?)</\1>}i', $value, $matches)) {
      foreach($matches[1] as $key => $tag) {
        $text = $matches[2][$key];
        $anchor = $sanitizer->pageName($text, true);
        $anchors[$anchor] = $text; 
        $full = $matches[0][$key]; 
        $value = str_replace($full, "<a name='$anchor' href='#'></a>$full", $value); 
      $hanna->value = $value; 
    if(count($anchors)) {
      echo "<ul class='jumplinks'>";
      foreach($anchors as $anchor => $text) {
        echo "<li><a href='$page->url#$anchor'>$text</a></li>";
      echo "</ul>";
    } else {
      echo '';

    For better understanding you might want to install Hanna Code and or want to customize this for your needs.

    • Like 3
  9. That makes life a bit easier as it doesn't necessarily need critical business logic as validation, calculation, payments or whatever.

    Data structure

    My personal preference would be a data structure that consists of branches for countries, regions, years and other repetitive data that will later be referenced in each wine. And a branch with all wines.

    Combined with modules like PageFieldPairs or Connect Page Fields you could easily sync those datasets and references from one page to another.

    But every other structure might work here as well. It's a personal preference thing here.

    Update: You should use a more unique ID for each wine than the PW page ID. The SKU or EAN or whatever the data source can deliver. This can make updates easier in the future.

    Data sync

    This depends.

    • How often new wines will arrive?
    • How often a wine needs to be removed?
    • How often details will change? What will change?
    • Do details need attention (for example: price formatting)?

    A manual CSV update might work well, but JSON makes things easier sometimes.

    Maybe I can find something about structure and sync in my files and projects that I can post here.


  10. Just some more thoughts on this topic


    I just asked myself Why would someone use Drupal or Typo3 and therefore read what they write on their sites. 

    The shocking truth is that they don't say anything new at all.

    Some arguments are valid, some are BUZZword Bingo but almost all of them match perfectly well with ProcessWire, too.
    If we wanted to create a huge list of arguments for ProcessWire we can find a lot of material out there in the interwebs.

    Can ProcessWire compete with Drupal or Typo3?
    I think we all know the answer.


    Next step Who uses Drupal or Typo3.

    This is way more interesting to look at.

    Big companies, big budgets and big agencies.
    Absolutely well designed sites well presented. 

    Drupal plays the showcase-game very well. Every site gets a lot of attention. Not only a screenshot, a link to the website, a link to the creator and a few links to modules. Everything is a case study. Browsing the list of sites is a really nice experience and makes me want to try Drupal and built awesome sites.

    Could this be done with ProcessWire sites as well?

    Should we invest more time in presenting sites and projects?
    You guess it.

    • Like 6
    • Thanks 1
  11. I really like the idea and the direction this article takes but there is one thing that ... has some kind of aftertaste.

    You are writing ProcessWire ist sicher (ProcessWire is safe) and telling people that there are no documented security issues but linking out to a page that tells something different - at first people will only see:

    Github ... ProcessWire... Issues... Security... security... security...

    I know about PWs high level of security but even I had to take a much closer look at those issues.

    Your audience could get this horribly wrong without further explanations as they will not dive deeper into those issues.

    2017-11-28 16_51_22-Search · security · GitHub.png

    • Like 5
    • Thanks 1
  12. _init,php isn't a regular template file.
    It's more kind of a universal settings file with variables and presets you might need later on your page(s).

    So you could add the following line to site/config.php

    $config->prependTemplateFile = '_init.php';

    The _init.php in /site/templates/ will be included every page load and therefore the login check is always in place.

    Within this file you could and should add psy's / your code

    $loginPage = $pages->get('template=loginregister'); // in my case yours might be different
    if(!$user->isLoggedin() && $page->id!=$loginPage->id) { // checks if user is logged in and not on login page
      $session->set('returnPage', '/path/to/welcome/'); // set your welcome site

    This would redirect every user that is not logged in to your login page and sets the returnPage.

    Be careful with the check conditions. You might want to fine tune this check.

    • Like 2
  13. @AndZyk MapMarker is a nice module and does most of the things most people want. But there is still some overhead if you build and use your own Google Maps with custom scripts and markup.

    All @suntrop does and probably needs is grabbing lat/long from Google and saving it to text fields. A super lightweight solution btw.

    I played around with Profields: Textareas and the lat/long script.
    Still everything is fine. With and without language support and german language pack.

  • Create New...