Leaderboard

Last week’s post was about the new ProFields Combo field and it seemed like there was a lot of interest. Thank you for that, it really got me motivated to finish it and release it sooner rather than later. I am very excited about the Combo field and worked on it most of this week, hoping that I may be able to have the Beta version ready for release in the ProFields board by this time next week. This is a little more break than I like to take from the core, but the focused development time means it gets done a lot sooner, and likewise in a stable release state a lot sooner. Since I don’t have core updates to walk through this week, I thought I’d focus on some Q&A about the Combo fields. Below are questions that were asked either here in the forums or in the blog post. Please feel free to reply with any other questions that come up too. There are definitely cases where this type of arrangement Combo provides would provide some nice performance gains. And there are other cases where they might reduce it. Consider that fields on a page in ProcessWire are dynamically loaded when you access them. So when you access anything from a Combo field, all of the data in the Combo field loads at once (1 query). So if you’ve got 10 fields in a Combo field, and you are going to be using much of that data in the request, then you’ve just made some nice performance gains, at least relative to having those 10 fields split into dedicated/separate ProcessWire fields. On the other hand, perhaps you are rendering a list of pages, and you only need one or two fields of data from the Combo field. In that case, it’s less efficient than regular ProcessWire fields because you’ve loaded a bunch of data in memory that isn’t going to get used. So I would say Combo fields are great for data that you use when rendering a full Page, but not as great for cases where you are rendering lists or summaries of pages (where you might not be using much of that data). In the blog post I mentioned that Combo fields store data in individual DB columns, but also keep a separate index so that all of the combo data can be searched together. If that’s what you are referring to, I would say the primary downside of this storage method is that it takes up more space. It adds convenience and efficiency for searching, but at the cost of consuming more disk space [in the database]. This is something that may be beneficial to some and less so to others, and it may end up being an optional thing too. The index is similar to a JSON encoded version of all the fields. But it’s something that I think is worthwhile for another reason: backups. Like the Table field, the Combo field maintains a unique DB schema consistent with your selection of fields. Every time you save a Field, it checks the schema and determines whether to add columns, drop columns, or modify existing columns (and likewise for indexes). The JSON encoded version of the data is immune from data loss as a result of schema changes, so I see it as potentially useful as a way to backtrack, should it ever be needed. As for your question about other fields in ProcessWire, Combo stores it exactly the same way as other fields, with the only difference being that it keeps a separate combined index of data; and is able to because the core Fieldtype architecture enables it to do so. Why not use the same duplication approach with other fields? I can't think of any core fields where this type of storage duplication would be beneficial in the way that it is with Combo. Outside of the core, the approach might be worthwhile in ProFields Table though. Yes! Combo fields work in Repeater and RepeaterMatrix fields. Since Combo fields are not a repeatable type, they play nicely with repeatable types. They might look similar but they are also completely different. A page fieldset (FieldtypeFieldsetPage) is technically a single repeater item, but presented in a non-repeatable way. It’s a convenient way to make a group of fields that you could reuse across any number of templates. And in that respect it’s quite similar to Combo, at least in appearance. But that appearance is where the similarities end. Fields in a FieldsetPage are still individual ProcessWire fields defined on a template, and the Fieldset itself is an independent Page (an individual repeater item behind the scenes). So if you’ve got a FieldsetPage with 10 fields in it, then it’s still consuming the resources of 10 ProcessWire fields, plus 1-2 additional pages for structure. The goal of ProFields is to reduce the number of fields necessary to answer a particular need, and that is not the goal of FieldsetPage. If a Combo field can answer your need, it can do so a lot more efficiently than a FieldsetPage can. On the flip side, since FieldsetPage uses regular ProcessWire fields, it can support more types than Combo can. Nevertheless, once Combo is available, I would most often choose it over a FieldsetPage except in cases where I needed a type of field that only FieldsetPage could support. Yes, any field within a Combo field can be queried individually in selectors using the field.subfield syntax. For example: $pages->find(“combo.first_name=Ralph”); It’s just like querying a Page reference field on pages in ProcessWire. So far, my experience is that it can do all of the same things, and supports all of the same operators; whether querying text, numbers, Page references, selectable options, etc. There are technical differences behind the scenes though. All the data in a Combo field for a page is represented by a row in a database table, so matching some types of values (like multi-Page references) has to use indexes rather than lookup tables. This is similar to the approach taken in the Table field. Per last week's post, Combo fields can do one thing that other fields in ProcessWire can’t though. Because it keeps an index of combined data, you can perform text matching on all of the subfields in a combo field together, just by omitting the “subfield” from the selector. An example is that $pages->find(“combo~=Ralph”); would find the word “Ralph” in any of the fields in the Combo, rather than just the first_name field. So not only is it easy to do, but it can do that more quickly and efficiently than other fields in PW. Thanks for reading and have a great weekend!

That's sounds great and if this is available, I wonder if this might change your answer to @Robin S's question about using this approach for all fields in PW. From my point of view I have always had a bit of a love / hate relationship with Tall-Thin vs Short-Wide approach to data storage in PW. There are obviously huge advantages in flexibility with Tall-Thin, and I know that in some cases they are more performant to query, but other times they are much less performant. While I don't expect moving the PW core in the direction of the Combo field actually makes sense, I do think that using it in certain templates for all fields (except page name / title) might make sense.

Thank you Adrian, I love your work. Tried variations similar, but obviously not the right combo. You rock!

The module seems stable enough to bump to version 1.0. Notable changes Declare a private namespace, solving install issues Require the latest ProcessWire master version 3.0.165 Add a new panel type Add New Page which recreates the core add-page shortcut menu

I did Page title (Multi language) field empty after core upgrade to 3.0.165 · Issue #1291 · processwire/processwire-issues (github.com)

Here is a script I made for the import of thousands of customers. You have to save this as shell script (f. e. sync-customers.php.sh), make the script executable and execute it via command line (./sync-customers.php.sh).

Very much appreciate the tip. Had taken a look with code inspector, but must have stuffed up my typing, then tried way too many other potential options. Next time, if in doubt I will use Tracy to confirm. Can't believe I didn't think of that, Saturday afternoon brain is not working as well as I would like. Many thanks again!

Glad you got it working. The simple to figure these sorts of things out are to right-click on a field and "Inspect" to find the name of the field. Tracy's Request Info panel is also helpful to see all the settings.

$f->optionColumns = n should do the trick. I think that should apply the InputfieldRadiosFloated automatically.

@adrian Having the option in something like Combo is definitely a nice choice. But like with the Table field, it places limitations on what kind of fields you can use in it (focused on simpler types), and what those fields can do. The approach isn't nearly flexible enough for a "supports any kind of field" modular system like PW. For instance, you could never have the likes of a Repeater field in a Combo field, among others. So it's kind of limited and primitive in that respect. But for a focused purpose module like Combo, that's where I think this approach is really useful and worthwhile.

@adrian It's definitely possible, and maybe we'll add the option for that. For this first version though it loads all the data in the field in the same way that other PW fields do. But you are right that it would likely be relatively simple to have it load them dynamically.

Cloudflare announced the general availability of their new Web Analytics solution today (even for non-Cloudflare-powered sites): https://blog.cloudflare.com/privacy-first-web-analytics/ I'm quite excited about this, as I've been looking for a solution that's both privacy-friendly, free for personal sites and GDPR compliance. In particular, being able to collect visitor statistics without tracking any personal data is an attractive proposition, since it doesn't require consent even under the GDRP. I looked at various alternatives, but all have their caveats: Google Analytics is out for obvious reasons. Matomo is a solid choice since it can be configured to not set any cookies and anonymize IP addresses. However, it's use of fingerprinting is somewhat dubious, so it's a grey area whether you need consent to use it. A couple smaller alternatives like Netlify Analytics (for Netlify sites) or fathom look good enough, but their pricing isn't really feasible for small personal projects. I have added the Cloudflare tracking script to my tutorial site processwire.dev, for now I'll use it alongside Matomo. Will be interesting to see how their numbers compare to Matomo. What do you all think? Are there better alternatives out there?

@horst Hm that's interesting, though I'm not sure if that would be enough for me to call it a day ... I've found that in many cases the Datenschutzbeauftragte don't have a solid grasp on the technologies and what actually constitutes PII, so they basically judge compliance of a tracking mechanism based on whether it sets cookies or not. Even though fingerprinting is much more perversive and there's no real opt-out for that. I'm also fairly certain that using Matomo with cookies requires consent under GDPR – since it allows you to identify returning visitors, you can collect pseudonymous information, which requires consent. I'm surprised the Datenschutzbeauftragte of NRW would make such a blanket statement, and I don't think it would hold up in court (not sure if the written statement would help there, I'm not a lawyer ?). But even without cookies, it's a gray area at best. The reason people jump on the cookie debate while ignoring other mechanisms such as fingerprinting is probably because the legal precent (most notable the EUGH decisions) have mostly been about cookies. So right now there's a grey area regarding fingerprinting. But I think as soon as there's a test case / precedent fingerprinting will be shut down the same way consent-less tracking cookies were shut down. Anyway, regardless of the current legality I think it's a good approach to drop cookies and fingerprinting in favor of referrers to differentiate between visits and page views (as Cloudflare claims they do). Though we'll see how well it works and if it's as privacy-friendly as they claim ?

According to the bureau of the Datenschutzbeauftragte of NRW, germany: If you (self)host Matomo on the same domain or subdomain with anonymized IPs, you can start to use it without opt-in, regardless if cookie-less or a use with cookies. Only thing you must provide and respect is a opt-out option. Don't know if this is different in other Bundesländer of germany, but I have gotten a written answer with the above content from the NRW-bureau. ?

Thanks for the info. Plausible is also a nice alternative.

I will send out an expression of interest request nearer the time. I haven't yet decided on a criteria for selection. Current plan is PayPal IPN due to its multi-notifications types. However, I may also do PDT, but not 100% sure at this time. No decisions made yet regarding Stripe's implementation. All frontend implementation is up to the developer. You will have the API at your disposal to do whatever you need to do. In the backend/model, orders can have different status (paid, unpaid, complete, partial, etc). Order line items also have individual status (returned, delayed, refunded, etc). This means you should be able to implement a pre-order feature yourself by, for example, marking an order as unpaid, in progress, etc. Padloper 2 does not render anything in the frontend. It is like ProcessWire. There will be no more in-built Padloper templates. You implement Padloper 2 however you wish using the API. I will, however, as part of the technical documentation, write a tutorial on ajaxifying the frontend. In addition, a separate frontend commercial module (fully functional frontend shop) is in the works. Good question :-). Padloper 2 does not utilise a single ProcessWire field, nor any custom ProcessWire fields, nor any ProcessWire pages (except just the one for the Padloper Process Module). All data is stored in custom Padloper tables. Having said that, it uses ProcessWire selectors just the same way you are used to, offering the same security and ease of use you are used to. You won't have to learn a new syntax. In addition, it is fully multilingual (descriptions, titles, etc). I plan to do a write-up of this when I'm done, a sort of 'the making of Padloper 2', the iterations, decision made, etc. No, you won't be able to do this. Not this way. There are no (ProcessWire) pages in Padloper 2 :-). That said you would still be able to use hooks. You've got some very interesting (albeit very advanced) ideas/thoughts there. Whilst not yet planned, when the dust settles, I'd like to further discuss/explore some of these with you. I cannot make any promises as to the outcome. Yes. There are four types of products (housed under Shipment Type). Physical Products that require shipping. Physical Products that do not require shipping (POS, etc). Digital Products. Products that are Events or Services (e.g., booking system). ---------------------- I hope I have managed to answer all your queries. I decided to just do it inline. I might reference some of the responses in the first post if I need to. Thanks.

I would like to take this opportunity to thank you once again for your fantastic support yesterday and today.

This week we’ll take a brief look at a powerful new ProFields module for ProcessWire that’s just around the corner—the Combo field: https://processwire.com/blog/posts/about-the-new-processwire-profields-combo-field/

@cjx2240 This depends on the selector you use to grab those pages. In the example, a $post->get is used, meaning it will be retrieved, by-passing restrictions. Are you using similar code? Please see documentation: https://processwire.com/docs/selectors/#access_control ps: I am not sure if ->child is also get-like.

See this Comments Fieldtype documentation page sections on customizing output and styling output. While it makes it easier, you don't actually have to use the built in methods for rendering the comments list or form. You can create your own markup entirely if preferred. However, I do think it would be worthwhile to copy or extend ProcessWire's /wire/modules/Fieldtype/FieldtypeComments/CommentForm.php file to your own class (MyCommentForm) in /site/templates/. When you want to render your form, you would do this: include("./MyCommentForm.php"); $form = new MyCommentForm($page, $page->comments); echo $form->render();