netcarver

Hi @bernhard, just starting to try out your module and am having a little trouble.

I've added this file to my /site/ directory and was expecting to the a new rmdemo field and template - with the rmdemo field added to the template. Both the field and the template are created fine when I reload the modules - but the rmdemo field is not added to the rmdemo template. Am I missing something?

<?php declare(strict_types=1);
namespace ProcessWire;

/** @var RockMigrations $rm */
$rm = $this->wire->modules->get("RockMigrations");

bd('Create field + template via RM');

$rm->createField('rmdemo', 'text', [
  'label' => 'My RM Demo Field',
  'tags' => 'RMDemo',
]);

$rm->createTemplate('rmdemo', [
  'fields' => [
    'title',
    'rmdemo',
  ],
  'tags' => 'RMDemo',
]);

@teppo, that might work if we combine it with an idea from @adrian. If we set a high initial value for ids (say 1 million) and allow pages using the user template(s) to use these independent autoincrement IDs at whatever rate the users sign-up at. We could try using our own, sub-1,000,000 counter value when adding pages with any other template. There won't be that many of them and we going to share these pages amongst all the installations anyway.

Hi @DaveP, thanks for the idea.  Hadn't thought of that - but I think it will become difficult to pull off, especially if we extend to other regions and have to sync 3 or 4 (or more) installations.

I'm working with a client that uses PW to provide the basis for various services, and GDPR/legalities mean that the data for our EU-based users has to live on an EU-resident server. Similarly, US-sourced data has to live on US-resident servers. As the sign-up rates are different in each region, the page IDs between the sites quickly get out of sync, so when new features involving pages are added to the US and EU sites, the IDs of the pages housing new options/blog posts etc are out of sync between them - making references to the pages in the code-base using the page ids impossible.

The only thing causing the desynchronisation between the installs is the user pages.

I know we can use different programmatic techniques to reference these feature/structural pages, but I'm curious; is it possible to force users (any page using the user template - or any alternative user template) to use a separate auto-incrementing id in PW?  I don't think so, but if it could be done, how would you approach this?

Being able to have fixed ids for landmark pages, despite differing sign up rates across regions, would be handy.
 

The newer versions of symfony/yaml require a pretty recent version of PHP - so you might need to use an older version of that library if you do go down that route.  If you don't need Yaml support, then removing it might be better.

@bernhard I use redis alongside PW on some client sites (using php-resque for background jobs like email composition and send) - though I do not use this particular module in production yet.  I think bitpoet is aiming for an API-compatible drop-in for wirecache that leverages the lower latency of redis' in-memory accesses.

Is anyone out there working on a Crowdsec bouncer integration for ProcessWire?  I know there's an official module for WP - but wonder if anyone has considered, or is currently working on, a port or native version for PW?

@valan You can use PWGeeks to search for docker-related PW stuff. Try this for starters: https://pwgeeks.com/?q=docker

So it is ublock-origin. Thank you for the pointer - I should have checked that first!

Updated to add 1: I actually run UBO in all my browsers so there must be a settings difference between UBO in my FF and Brave installs - will look into it.

Updated to add 2: Found it in case anyone else is interested. There's an entry in the UBO blocklist called "Fanboy's Annoyance" for .privacywire-wrapper that is causing the issue.  I had this list enabled in FF but not in chrome.

@ngrmm Thank you for the quick reply.  So I have the checking of DNT set off in the module settings, which should make it ignore the browsers DNT setting (I think).


I'll look at other browser/extension settings as I do run ublock origin.

Has anyone noticed any issues getting this module working in FF?  It seems to work fine in Chrome based browsers but in FF for me - no errors in the console either which seems strange.

@cpx3 Were you able to revert to the previous installed version to restore your site's operation?  Also, if you look in site/assets/logs for the latest entries in the error.txt and exceptions.txt files, you may get a better picture of what's going on - and if you are running PHP with error logging turned on you can look in the PHP logs too. The exact location of these files (and if they are even used) will depend on your php.ini file.

@Zeka Thank you, I will give that a try as well.

Updated to add: Yes! Using boot.php works nicely, I can now stick with PWs own autoload mechanism, thank you for the suggestion.

Update: I can get the trait composition to work by adding a psr-4 clause to the autoload part of the root composer.json and then running composer dump-autoload from the command line.  Not ideal, but seems to be the only way I can get the autoload information in to PW in time for it to use it when creating the UserPage class.

Thanks for the reply, @thetuningspoon I did try extending the autoloader in init.php instead of ready.php but it seemed to make no difference. The only thing that seemed to work for me was a direct include of the trait file from within site/classes/UserPage.php. Will try again though in case I did something wrong first attempt.  No, still getting that error when it comes to autoloading for UserPage regardless of the location of the extension to the autoload mechanism.

Quote

You could also use a PW hook to add this function to both classes, although it wouldn't be as elegant.

Actually, that might work fairly well in this case, though I'd really like to be able to get to the bottom of the autoloading.

Hello,

I'm starting to play catch-up with some of the recently (and not-so-recently) added features to PW. In particular, I'd like to ask about more complex uses of Page Classes.

I have a site where the end users are actual PW Users with first and last name fields. I also have several other templates in the system that have the first and last name fields but they are not actually Users of the system, rather they are entities like Contacts or other personages that can be also be named.

I thought I'd enable page classes and add a simple getName() method to the UserPage class to allow their name fields to be nicely concatenated. In itself, no problem, as long as I remember to extend from User. So here's exhibit A: UserPage.php...

<?php
namespace ProcessWire;

class UserPage extends User
{
    function getName() {
        return trim($this->first_name . ' ' . $this->last_name);
    }
}

This works fine, I can call getName() on my users, nice.

Now, my other nameable entities need this function too. I can extend from UserPage to inherit the getName() function, which works well and is straightforward...

<?php

namespace ProcessWire;

class ContactPage extends UserPage
{
}

So I can now use $contact->getName() as well as $user->getName().

But, my contacts aren't really system users, so I'd prefer not to inherit from UserPage at all, but either inherit from some intermediate class representing some form of NameableEntity or else use traits to compose the functionality into the individual page classes which need it. However, I'm hitting snags with both approaches and would appreciate some feedback.

Attempt at Traits
So I add the following as site/classes/NameHandlingTrait.php...

<?php
namespace ProcessWire;

trait NameHandlingTrait
{
    public function getName() {
        return trim($this->first_name . ' ' . $this->last_name);
    }
}

And switch my ContactPage.php over to using it...

<?php
namespace ProcessWire;

class ContactPage extends Page
{
    use NameHandlingTrait;
}

And that works. I can access $contact->getName();  (I actually did it by setting up the wire autoloader in ready.php to look for a specific namespace in a traits/ subdirectory - but I'll skip showing that here, it did work for my page classes that extend from Page.)

However, when I try switching UserPage.php over to the same trait code to keep it DRY...

<?php
namespace ProcessWire;

class UserPage extends User
{
    use NameHandlingTrait;
}

I immediately hit the following error: "Fatal Error:  Trait 'NameHandlingTrait' not found (line 5 of /site/classes/UserPage.php)" either when visiting the site (front end or admin) or by bootstrapping from the CLI.

I can overcome this by manually requiring/including the trait file at the start of UserPage.php - but I'd much rather autoload it if at all possible.

No matter how early I try to declare the extension of the class loader to attempt to autoload the trait, it isn't soon enough and I always hit the fatal error shown above.

Can anyone shed any light on this?  How do you go about using the PageClasses, especially UserPage, when the structure might need to take more of a composition-rather-than-inheritance form?  Also, if you have any suggestions as to other places to get autoloading set up in PW prior to init.php or ready.php I'm all ears. I tried setting up the autoloader mappings in both places and they work for classes derived from Page but not for UserPage - so I suspect PW is creating a User instance pretty early on in its bootstrap, well before it is loading in extensions to the autoloader.

I'll try adding a PSR-4 clause to composer.json and dumping the composer autoloader next - but I'd rather stick with native PW autoloading if possible.

Intermediate Base Class

The other approach I've tried is to use an intermediate base class to house the getName() function and inherit from that. This is doable for the classes derived from Pages but again, I hit the snag that the UserPage seems to have to extend User, and not my base class.

@ryan What would you recommend here?  Could UserPage extend something other than User?

@fruid Not 100% sure what's going on, but running grep in the site/modules/wireMailSmtp/ folder shows it's using mcrypt functions on lines 67, 68 and 79 of smtp_classes/ntlm_sasl_client.php - but mcrypt was removed from PHP7.2. It might be that @wbmnfktr isn't running into the issue if his setup is connecting to an smtp server without using ntlm_sasl.

Is the SMTP server you are connecting to using Windows by any chance? (This might be a wild-hunch)

Looks like that file was originally part of PHPMailer - and there are some posts about fixing it to work with NTLM that are more recent. Like this one: https://cheesefather.com/2017/06/phpmailer-ntlm-ms-exchange-smtp-authentication/ (though for a different hash() issue). You might be able to use that to patch your local copy - or otherwise look for a more recent version of the ntlm_sasl_client class.

@teppo That would do it, thank you :)

Yup: Works great.

Hi Adrian,

Is it possible to extend Tracy's definition of local host in some way? I'm running my sites out of docker containers on my local machine and can't get it to force guest users into development mode - probably because of the internal IP address assignments to the docker bridge networks. When I visit my site from the browser on my host, the visit has an IP address in the 172.16.x.y range. I'd like to be able to force guests into development mode for a specific visiting IP or block if that's possible.  May be something in the settings for this already that I've missed.

Regards,
Steve

Easy to hit a key combo to go to the end once in the editor. I'd axe the line number from the link.

@teppo Maybe Soma's LogMaintenance module would be useful?

Is your website built using ProcessWire?

You're misquoting me, @bernhard :)  Could you try this...

<script>
   var evtSource = new EventSource("sse.php")
   evtSource.addEventListener('ping', function(event) {
       var data = JSON.parse(event.data)
       console.log(data)
   }, false)
</script>

Nice, are you using mermaid-js for the diagramming?

Hey, @Adam, thank you!