ProcessWire 2.6.21 upgrades comments + more on PW 3.x

ProcessWire 2.6.21

This week work continued on ProcessWire 2.7. We fixed several minor issues as reported in GitHub issue reports. This week we also added a new feature that users of the comments field might be interested in… ProcessWire 3.0 made a lot of progress this week too!

• New star ratings for comments fields
• More updates on ProcessWire 3.0

New star ratings for comments fields

This week we upgraded the core comments field to support a 5-star rating system that can accompany each comment. This is something that's been requested a few times, and it tied in directly with client work in progress this week, so it found its way into the core.

When enabled, anyone submitting a comment can choose to rate the subject they are commenting on using a 1-5 star scale. This is likely to be used in instances where you are using the comments field for reviews, as opposed to just blog comments. Though I've enabled the star ratings here so you can try them out (scroll to the bottom and leave a comment). Or for an example with better context, check out the comments for a bike tour on Tripsite like this one where I've left a comment as an example. Special thanks to Tripsite bike tours for sponsoring this new feature.

To enable the 5-star rating system for your own comments, upgrade to the latest ProcessWire (2.6.21)* and in your admin go to Setup > Fields > your comments field, and click the "Details" tab. Scroll down to the field "Use star ratings?" and enable it from there. You can choose to make star ratings optional or required.

*If you want the star ratings system but are using the current stable PW 2.6.1 master, you can always just replace your /wire/modules/Fieldtype/FieldtypeComments/ files with those from PW 2.6.21, as there are no other dev branch dependencies for this particular new feature.

More updates on ProcessWire 3.0

In addition to preparing ProcessWire 2.6.21, much of the time this week went towards continuing work on ProcessWire 3.0. This week the focus was on multi-instance support and I'm glad to say we are now there–hopefully! Though I'm not going to suggest you start testing it out just yet, as I need to do a lot more testing here before I take up your time. But in initial tests here, multi-instance support is working well and I'm able to successfully have multiple PW installs talk to each other while running from the same core.

We will definitely be using the new multi-instance system here to make our currently-separate processwire.com, modules.processwire.com, cheatsheet.processwire.com sites talk to each other and share data. Once I've spent more time in testing here, I'll follow-up in a future post with some practical examples, as well as code examples of how you can try it out yourself too.

The rest of this gets into the technical details of how it works–the stuff I love to talk about, but that I know probably isn't that interesting to most. So if you aren't interested, feel free to skip this next part. But if you are a module developer, you may want to read on to learn a little more about how you can also support multi-instance in your modules.

Achieving multi-instance support involved changing the entire manner in which ProcessWire's API variables work. In ProcessWire 2.x, API variables use a static container that is shared among all objects descended from the Wire class. For that reason, you could only ever have one instance of ProcessWire available to the API. In ProcessWire 3.x, we've switched to a dependency injection system. API variables are now injected to each newly created object when appropriate. Meaning, you could have multiple Page instances in memory, wired to different ProcessWire instances.

Multi-instance with 3rd party modules and PW 3.x

These will enable your modules to be able to support multi-instance too:

• If you are using procedural calls like wire('pages') use method calls like $this->wire('pages') or properties like $this->pages instead (usage of $this is the key). That ensures that your module is using the injected dependencies, rather than static ones.

• In 3.x, if your module creates new objects, like $page = new Page();, you'll want to wire those new objects to the current ProcessWire instance, which makes it a "wired" object. You do it like this: $page = $this->wire(new Page()); If a given object is not wired, then it gets its dependencies from the last accessed ProcessWire instance. For this reason, making new objects wired isn't a requirement, but it's a best practice in 3.x. Any objects that you get from ProcessWire's API are already wired, so you really only have to consider this if you are creating new objects.

• For configurable modules, stop using the static getModuleConfigInputfields() method, and instead use one of the alternates: a ModuleConfig class, a module configuration array, or simply just remove the "static" keyword from your existing getModuleConfigInputfields() method. Any of these alternate module configuration options should also be supported by PW 2.6/2.7, so it's something you should be able to do now rather than waiting till 3.x.

By the way, the old wire() procedural function (without $this before it) that you may have used, is still there in 3.x. But because it exists out of the object/instance scope, it can only refer to the last accessed ProcessWire instance. It is just fine to use it in your template files, as PW notifies wire() what the instance is going to be before rendering a template file. But when in the scope of a module or an object, the non-procedural version $this->wire() is preferable. Though that's already been the case in 2.x too.

Hope you have a great weekend and remember to visit the ProcessWire weekly.

Comments

• 

  ryan

  • 4 years ago
  • 186

  ★★★★★

  Hello.

  Reply

  • 

    Pierre-Luc

    • 4 years ago
    • 20

    ★★★★★

    Is this me you're looking for?

    Reply

    • 

      willyc

      • 4 years ago
      • 31

      i.can see it
      in ur eyes

      Reply

• 

  ryan

  • 4 years ago
  • 61

  ★★★★★

  The API is staying the same. The bit of code you wrote wouldn't work in 2.x or 3.x. :) Access to all of PW's API variables remains the same regardless of whether using namespaces or not. So the correct call for your code in either 2.x or 3.x would be $page->image_field->first()->size(500,500)->url;

  Reply

• 

  Tom

  • 4 years ago
  • 20

  ★★★★★

  I have never really looked at Namespacing in PHP or multiple instances, I haven't really had to. However, this is looking very promising for those who require that.

  How does this effect people who do not need to use Namespacing? Will the API be as simple as always? Or will templates now have to have $this->$page->image_field->first()->size(500,500)->url for example.

  Reply

  • 

    ryan

    • 4 years ago
    • 81

    ★★★★★

    By the way, you won't have to change anything in your template files for multi-instance. Using $this isn't necessary because PW already injects the proper API variables for the correct PW instance into your template files. Where you'd want to use $this->pages or $this->wire('pages'), rather than wire('pages') would be in PHP classes descending from Wire, such as in most modules. Most modules already do this in a way that's compatible with multi-instance, but there are a few (including some of mine) that just use a procedural wire('pages') call. That's where we'll update to make it $this->pages or $this->wire('pages') ... it doesn't matter which since they are equivalent. I usually use $this->wire('pages') just because it's a little more clear to me that it's referring to an API var rather than potentially some other variable in the class.

    Reply

• 

  Nico

  • 4 years ago
  • 61

  ★★★★★

  Great work as always. I should spent more time with ProcessWire again but at my current job we're using meteor.js and there is just not enough time at the moment (next to university and work). But I try to keep up with this updates each week so I won't miss a thing ;)

  Reply

• 

  Teppo

  • 4 years ago
  • 30

  ★★★★★

  On a (very) loosely related note, could the comments system do something to avoid accidental double-clicks, or perhaps allow users to alter (or just remove) their comments for a brief amount of time?

  Reply

• 

  Teppo

  • 4 years ago
  • 40

  ★★★★★

  I may be in a minority here, but I actually found the 3.x license update way more intriguing than any of the other changes. Ryan, would you mind explaining briefly what's that all about? :)

  Reply
• 

  Ryan

  • 4 years ago
  • 00

  ★★★★★

  Supporting a more open license is content for next weeks blog post as I'm still dwelling and experimenting a bit there. There's more discussion on that here: https://processwire.com/talk/topic/11277-pw3-core-licence-change-from-gpl2-to-mpl2/

  Reply

• 

  gebeer

  • 4 years ago
  • 10

  ★★★★★

  The star rating system is great, thank you!
  One improvement would make it even greater: add schema.org markup to make ratings visible in SERPs etc.
  And can we show aggregate ratings?

  Reply

• 

  Jim

  • 4 years ago
  • 00

  Do you think the star rating system is relevant to the Almanac of Architecture and Design? I like the tech. Just not sure its a fit for us.

  Reply

• 

  Alan

  • 4 years ago
  • 00

  ★★★★★

  I'm about to need to use comments again—it's yet another lovely PW thing to find that in the interim the core has improved in this area, thanks all! ^_^

  Reply

• 

  Can

  • 3 years ago
  • 00

  ★★★★★

  "..multiple PW installs talk to each other while running from the same core."

  Would it be possible to have a local copy talk with the live version? I'm new to namespacing and multi instances. As I understand the quoted text, they need to be on the same machine, right? But with namespaces, would it be possible to e.g. bootstrap the live install from the local copy and have the local copy publish to the live version?

  That would be amazing :D

  Reply