Leaderboard

Just had a very interesting conversation with @wbmnfktr and wanted to share this little preview of a quite big upgrade coming soon called "RockGridActions". I'll share some more infos soon. The great thing about it is that it is built modularly so that we'll be able to use it almost plug&play for RockTabulator ( @Beluga)

In this post we take a quick look at the new version of ProFields Repeater Matrix, yet another new version of FormBuilder, and a new version of the GoogleClientAPI module— https://processwire.com/blog/posts/lots-of-module-updates/

We recently finished the relaunch auf camac.de, a client from the software industry, focused on controlling and business integration solutions. Concept, design and implementation by schwarzdesign. The site is focussed on longer content pages with text and image combination, with technical information for potential customers. It also offers multiple options for Call-to-Action elements to maximize conversions. Finally, the site is heavily optimized with caching and minification at every stop to be instantly readable even on slow connections. Features No hard-coded sections in any template: Almost all content types use the same repeater matrix field with several section types. This way, the entire site and all parts of the layout can be moved around and combined in any way imaginable. Custom Call-to-Action options: Two different contact forms, custom external links or a general CTA text. Automatically generated page navigation and human-readable anchors (as seen here) Every page fully loaded and interactive in ~1 second, even on poor mobile connections Automatically generated SEO meta tags, with overwrite fields available on every page Modules used ProFields FormBuilder Tracy Debugger Sitemap Duplicator ALIF - Admin Links In Frontend WireMailSMTP Content and conversions Every visitor is a potential customer - this is why we made sure there are ample opportunities to generate leads. At the end of every page, there are multiple options for the CTA section: A contact form with a customizable message (built with FormBuilder) A download form that allows visitors to download PDFs (e.g. the full article) in exchange for their name and E-Mail address. Other text + image combinations with custom links or buttons. The download form was custom coded, as it allows the editor to upload a file specific to the current page and make it available behind a small form. After successfully submitting the form, an e-mail is sent to the site owner, and the file is directly streamed to the client as a download. Technical insights This is one of the first pages where I used Twig for templating, and it's been a great developing experience. With Twig, you get content escaping and much better seperation between logic and view / display. I also spent some time working out a solid structure for the twig templates, with useful defaults, reusable blocks for page and section template (you can read more about the approach in my recent tutorial on integrating Twig with ProcessWire, part 1 and part 2). I also started using Parcel as a lightweight alternative for Webpack, when all I need is to compile a couple of small scripts (for the navigation, the lightbox, a dismissable cookie notice et c). What's great about parcel is that you get bundling of your own code and external libraries out of the box, as well as ES6+ transpilation and minification for production usage. Still, it required no configuration but a couple of command line options. This way, you get one bundled, minified JavaScript file, the same way we produce a minified CSS file with SCSS, but without the additional overhead of configuring Webpack. Screenshots

ok, too early... ? ...at least we managed to make this a hot topic: ?

https://adrianbj.github.io/TracyDebugger/#/debug-methods?id=dump In case you haven't installed Tracy Debugger yet, you should do it NOW ?

try: $products = $pages->find("template=product, limit=9, sort=sort" ); if($products->count() > 3) { } https://processwire.com/api/ref/wire-array/count/

Hi! Been doing some basic Twilio implementation for a client to enable them to automatically send text messages to registered users on page publish. As an upshot, I thought I would strip out the site specific work and stick up on github here: https://github.com/benbyford/TwilioChannels This modules pulls in the Twilio APi and enables you to send SMS messages from your front or backend. Send SMS message Truncate message to single message character limit Auto-select number from range of numbers depending on $To number country of origin–this enables you to send messages with a local number to that user if one added to the config. Templates usage: $twilio = $modules->get("TwilioChannels"); $twilio->sendSMS($toNumber, $message);

@Autofahrn is right.

Are you aware that you can fully rewrite the UIKit admin theme? Just copy the wire/modules/AdminThemeUikit folder to site/modules/. The next time you load a page in the backend, PW will ask you which version you'd like to use. You can even choose if you'd like to use SASS or LESS, iirc. If that's overkill for you, you can just override paddings and margins if you write / load an extra admin.css. But the first thing you should consider, is to simply configure the admin theme via GUI @ site/backend/module/edit?name=AdminThemeUikit&collapse_info=1 And of course, PW lets you define borders, paddings, margins and background-colors on a per-field basis.

Much love to you and your family Ryan, haven't had that experience before, and not looking forward to having it in future - cats make a bigger difference to your life than you'd think! Thanks again for all you do.

Ha ha! Thank you for all your help. I did use Tracy Debugger when I first started and I wasn't skilled enough for it to be helpful... I will try that again! Good idea!

Damn, I am very sorry. I mislead you. I thought it returns false, if the count fails, but it turns out, it really returns the number. Sorry. I updated my example above, which is basically the same as @Autofahrn's

For me the count() always returns the amount of pages found, regardless of its argument. But I'm on 3.0.123 still...

Yes sorry! Jumped ahead too fast! Now I am in intrigued too ? Could you throws us a lead @jens.martsch ? Like, I cannot find PaginatedArray or PageArray classes to have their own implementation of count.

Imagine you have a nice conversation with someone and only a few hours afterwards you are knee-deep into a module and possibilities you never thought of. Thank you @bernhard for hijacking my plans for the weekend. ?

that's clear. But to fulfill the initial request, $products should hold the full result from the find in case it contains at least three elements. So PageArray::count(int) is expected to be something conditional and returns the full array if the array contains the requested number or something empty.

Even shorter: $products = $pages->find("template=product, limit=9, sort=sort")->count(3); if ($products) d($products);

Thank you!

I dont think I have it down yet. I really think a page builder needs to live update while you change fields to be competitive with things like DIVI and Beaverbuilder and Elementor. This is what I am working on with vue. I am just looping through all fields attached to the page and making vue form fields that have 2 way databinding. So when you type new text in, it changes as you type. Or if you hit center text, it centers it instantly. I am using the REST API plugin to push the page data back to the database when you hit save. I plan on releasing the site profile to the community when I am done. It should be better than the above wordpress solutions as they are very hack solutions. You can not, for example, add any element inside a tab module or an accordian. You can only type manual code into their rich text. With mine, I can add a grid with columns or really anything inside anything.

Nice work joer80. Looks great. I am wondering though, how many fields would you count in your profile as only the Tab_open takes two per section so unless you use some tricks, you might end up with a huge fields list? Btw, after completting my two category blocks with all the bells and wistles I realized that instead of using one tab_category attribute and set its type to asmselect I used 10 fields (tab_category_1, 2, etc.) which caused me some troubles to check the array for empty values, then sort them out etc. I am working on redoing the markup which would simplify a lot the code and would be much easier to "digest" and re-purpose. ProcessWire keeps amazing me every single day with the freedom of code, approaches, functionality OOB etc. It really applies to the saying: Sky is the limit!

Here I'm introducing FlipFall Magazine, our multi-topic blog. It used to run on Wordpress but we recently switched it to ProcessWire. This was done the usual way we do it when converting our sites: install ProcessWire in a subfolder of the original Wordpress site under a hard-to-guess name, set up the new site there, then move content over manually, inspecting and updating each article as needed. After the ProcessWire site was ready, when we un-installed the Wordpress one and moved the ProcessWire site up one level to the document root, and... done. We used the W3CSS framework because it handles the responsive breakpoints so well (no extra work for us ?), and it tends to default to a clean modern look. We wanted full control over the back end of the site and do customized things without having to hire a developer. As FlipFall has grown, the ability to have in-house back-end control has become even more important. Case example: Ad partners - we now can quite easily, if we wish, place different ads on different topics on this blog at a moment's notice - no need to hire a developer. Changes like this can be implemented in-house right away. The fact that we can easily incorporate this sort of thing is really nice when we're talking with potential ad partners. Helpful features of ProcessWire during this experience: The ability to export and import fields in PW was key here. We had a few other article-style sites I had done in PW recently, so having the same types of templates was very helpful. We were able to export fields and templates from our existing sites and import into FlipFall as a starting base point. No need to re-invent the wheel here! Another helpful ability of PW was when we were dealing with the categories. We built the site without category templates (but with the category page field), then added the templates in later as needed - no disruption. In other words, a template-less page field worked perfectly for the categories until we needed the template, then we just created the template. Not every feature of the site needs to be thought out in absolute full beforehand, some can be added in later as needed. Very extensible and convenient. Internal links within blog posts worked well using the page select option in the link button on the editor. When moving out of staging folder and into document root, the links auto-updated, which was nice. Creating new articles is a breeze, because under PW our fields are now customized for our needs: we created all of the fields we need and none of the ones we don't. Again, this is unlike most blogging CMS's, where they try to guess what you want (and usually get it wrong). Even for people who are solely doing blogs/article sites, I feel that ProcessWire is a much better option than most blog-specific platforms, because of PW's flexibility. The only thing I miss about Wordpress is the ability to auto-schedule post publication, which for the serious blogger is important. For example, there were some occasions on some of our other blogs where we needed to schedule posts to auto-publish at 3:01am Eastern Time to allow a time-sensitive post to come out as early in time of day as possible on publication date (3:01 am US Eastern time ensures it's that same day 12:01 am on Pacific time). We were delighted to see that ProcessWire is much, much lighter on resources of the hosting environment than the same site on Wordpress - we could see this empirically on our web hosting stats before and after the switch.

First of all thanks for the nice write-up and congrats to your re-launch. I'm curious: If you install a sub-directory into a WP site, or let's say just a .php file at WP root, it can't be accessed due to WP's own redirect (.htaccess) rules. Did you have to add some .htaccess exception for this? There are two modules out there. They seem to be quite old, but did you consider using one of them anyway? I agree that an "out-of-the-box" solution would of course be preferrable. Feel free to add this feature to the wishlist / roadmap list (if it isn't there already).

If any of the alternatives work I'd still wonder why his original code wouldn't work.

You could try $matches = $pages->find("template=expertsItem, location=$location, department=$department, sort=expertSurname")->not("department=2131");

$selector = "template=expertsItem, location=$location, department=$department, id!=2131, sort=expertSurname"; ? or if you're trying to exlude the page you're on, you can use id!=page.id

So, I uninstall and reinstall the site. I discover the problem. I try to modify and remove i 2 "#" by pannell hosting, NOT BY FILEZILLA. Now, my site work very well with certificate https://. My personal lesson: NOT USE FILEZILLA FOR TO EDIT FILES!

I had an edit button that edits the page you are on, but I am playing with just making it highlight all of the sections on the page and make an edit button for that section. See this video. I dont like how it doesnt give you live preview though, so I am playing with vue to do this.

Great to see updates to the major pro modules. Looking forward to new RepeaterMatrix version!

Snippet to easily add Inputfields with intellisense support ? "Get PW Inputfield": { "prefix": "field", "body": [ "/** @var Inputfield$1 \\$${2:f} */", "\\$${2:f} = \\$this->modules->get('Inputfield$1');" ], "description": "Get PW Inputfiel" }, PS: Turns out that the chaining syntax as shown in the demo does not properly work with intellisense, so I'll use single line method calls in the future ?

Hi, I've added an addInlineImage() method to https://github.com/chriswthomson/WireMailMailgun <?php $img = $pages->get(1)->images->getRandom(); // An example $customFilename = "test.$img->ext"; // Don't want to use the basename for this example $mg = $mail->new(); $mg->to("your@email.com") ->subject("Test Inline Image") ->bodyHTML("<p>Testing, 123, is there an image for you to see?</p><img src='cid:$customFilename'>") ->addInlineImage($img->filename, $customFilename) // Second argument is optional ->send(); If the image isn't referenced in the HTML it just appears as a standard attachment from what I can see. Cheers, Chris

Hey @WillyC, nice to read from you again. (Long time no see.) ?

wire( 'sanitizer')->entities( $u->title ) => $url . $u->id, wire( 'sanitizer')->entities( $u->request_type->title ), wire( 'sanitizer' )->entities( $dog_ref->title ) => $url . $dog_ref->id, wire( 'sanitizer' )->entities( $mailer->name ), ... "<a href=''>Schváliť</a>", // u NO.entitties on this.ones

looks.ikes u w ant $table->setEncodeEntities(false);

I'm not sure if I can blame the PHP library alone. It definitely could be one of the things that contribute to poor performance. But there are many more things going on. For example permissions is a big one. The schema needs to check the permissions for each field and subfields. So if you have lots of page-refs and fetching their subfields, it will check if the user has permission to view those fields. When you make a query inside your templates, the script already got access and don't do permission checks manually. It needs to be improved. Performance is very important. But right now I'm dealing with PHP library deprecation, because it's not maintained anymore.

Hello! I have pages that have separated fields for first name and last name. I'm working on a search form that has one single input field, so that if someone search for "John Doe" it should find all pages that have "first_name = John" and "last_name=Doe" or, of course, "first_name=Doe" and "last_name=John". What would be the best use of selectors and operators in this case? I came up with first_name=John|Doe, last_name=John|Doe so that i should split the search key with | I'm not sure this is the best solution. What would you suggest? Thank you!

u want.to set for.use serveors timezine no client not big prolem if.u set wrong

@Nurguly Ashyrov awesome cast! Thanks for making all this and taking your time to make it awesome This is really cool stuff and opens up a lot of possibilities.

Hey @bcartier and everyone who is following. I implemented a basic language support. Nothing really changed, except now with LanguageSupport enabled in your ProcessWire app, the GraphQL api will return the content in whatever language the user is assigned. In addition, when Language Support module is activated, there is a language field in your GraphQL api. So you can request the exact language you want. It looks like this. { language(name: "de") basic_page{ list{ title summary } } } You need to put the language field on the top. Well, not exactly on top but just before fields that return translatable content, like title, headline, body etc. It's because GraphQL processes requested fields from top to bottom and it will not know what language you want till it gets to language field. Did you also know that in GraphQL you can query same field multiple times with aliases? Here, take a look at this { basic_page_default: basic_page{ list{ title summary } } language(name: "de") basic_page_de: basic_page{ list{ title summary } } } Curious what will be the response? Try this with site-languages profile and find out.

@Nurguly Ashyrov, this is really awesome. My front-end work is mostly JS/SPA work these days and I learnt to love the “headless”/“api first“ approach of commercial CMSes like Contentful. So I often thought about what a perfect and easy to manage back-end ProcessWire would be with a solid HTTP-based api built right in to allow uncoupling actual front-end/ui parts like admin and user interfaces (as actual self-contained apps) from the CMS itself. A module like yours makes a huge leap in this direction and will make ProcessWire much more interesting for a lot of front-end devs and e.g. as a flexible and fast to set up back-end for app prototyping/mvp development. A pity this didn’t exist 9 month ago!

Thank you @Werner Pilnei. I am excited because I like using ProcessWire . I try to do my best in introducing this module to the community. GraphQL is very young standard and is not mainstream yet. I intentionally started this thread in the Pub section, to make sure this is not a module support page but more a discussion on GraphQL (as this new api standard by facebook) and ProcessWire. To talk about how they could fit with each other, what ways we could use it, the new ways to use ProcessWire and so on. I personally never think about ProcessWire as a CMS. Though it is in fact a true CMS in its literal meaning, it is best at managing your content. But when people are introduced to ProcessWire it is presented as CMS and since the web is cursed by WordPress, people start using ProcessWire with wrong assumptions in their minds which result in negative impressions. I am generalizing here but when an average web developer hears CMS, she thinks it is a ready website with bunch of functionality baked in like tags, searching, blogging, commenting and so on. Those functionalities become the evaluation criteria and when they see that there is no tags in ProcessWire they count that as one of the things ProcessWire is missing. They don't understand that tags are something ProcessWire shouldn't have, because they are used to see tags in a CMS. I don't think that I am telling something new here. The community is well aware of this problem and the release of new site profile states that these problems are being addressed. But it doesn't have to be the only way. The modular architecture of ProcessWire allows us to extend it anyway we want, and this module is one of those attempts in presenting ProcessWire in different perspective. Even if it won't make much difference, I think we should keep trying and experimenting. Who knows what could come up along the way. I was only thinking about SPAs when creating this module. Never thought of PWA and usage with service workers like you approached it. Which is, by the way is great to hear. I hope there will be bunch of other ways people use it.

@Nurguly Ashyrov Hello Nurguly, I was following this thread from day one and I am deeply impressed by the passion you are putting into your 'baby'. Especially your in-depth explanations helped me understand your concept and getting first results on my own. Very often talented programmers do not have the same skill in teaching others . But you definitely have. Right now I am experimenting with your module to figure out if this could be a method to be used in a PWA (progressive web application). Using the GraphQL channel I would reload just my 'new' data via the service worker . Therefore it wouldn't matter that this data is exposed to the public - it should go there anyhow.

That will all depend on how you configure your api. If you wish this module can expose all pages in your website, including the system ones. Or you can restrict to some very limited data. There are more functionality to come, but at this stage the module supports: Template restrictions. You can choose which templates are enabled, but in addition it will conform to ProcessWire permissions. So you could limit access to certain templates only to certain user roles. You can enable access to only logged in users for example. Field restrictions. Also supports ProcessWire permissions. Including template context permissions. Meaning, you can allow title to be viewable for one template and restrict for another. Max limit support. Like the one you use in selectors. So users won't be able to get list of data for more than say 50 pages at a time. and also many other security options are on the roadmap: Built in field restrictions. At it's current stage api gives access to page fields like children, parents, createdUser..., or there are path, size, basename for files and images fields. Those will be disabled and available as extras. Query complexity limit. Currently you can build queries as deep as you want, to request ridiculous amounts of data. This will also be limited for only couple levels of complexity and you will be able to increase or decrease it.

For some websites this might even be the goal. But I can understand your reasoning. It might be interesting to be able to use the module to create endpoints with a somewhat fixed queries. Once the experimental phase is over and it goes towards production queries could be moved from the frontend to the backend.

in regard to the public / private part, what @blynx mentioned, especially the by PW default "private fields" simply needs to be covered via accessrights on fieldlevel, set by the dev who wants to use this module. There is no need for public/private endpoints in the module. Or I'm wrong? If you build a site without that module, you are done by simply use display logic in your templatefiles to control output of fields. If you want to use the module, you additionally have to mimik the accessrights via PW fields access settings. Thats how I understand it by just reading this really valuable thread. @Nurguly Ashyrov

Just a thought, since this is what I try to do with my own modules: could you add hookable methods in ProcessGraphQL that allow implementing custom restrictions? These hookables could be no-ops if not hooked and receive all information about the query at the time of calling, enabling users to filter or reject queries before or after they've run. It's an intriguing module in any case. Thanks for sharing it with us!

Generally speaking you're, of course, right -- in most cases one should use built-in visibility settings and permission-related hooks, but it's not unheard of to check permissions in a template file either. Depends a bit on the use case. And yes, you're right that in such cases it may be preferable to avoid installing such a module at all. Obviously this is mainly a problem with systems that include a enabled-by-default (or always enabled) built-in public API, and less so when enabling/installing the API itself is a conscious choice. Either way, it's good to understand that exposing your content to the world via a publicly queryable API may uncover some surprises. This is one of the reasons why I find certain value in the idea of crafting the API per current needs and so that it only exposes the minimum viable amount of data Note: don't get me wrong, I'm definitely not against this module. What I've said here is mostly theoretical. I also think that your idea of being able to manually define queryable templates makes a lot of sense. While I'd still suggest enabling a selector instead, you obviously know the use cases (and the implementation) better.

This sounds good, and that's basically everything that a "generic", publicly accessible API can do. I've got no complaints here What I've found out while playing with the WP REST API a while ago is that even though permissions are sensible, it may end up showing more than the public site. Part of it is about things like (not just page but) field level permissions, and part is about pages that exist and are publicly viewable for technical reason, but are not *intended* for public consumption, if you get what I mean. Surely it would be best to always use native permission rules to limit the visibility, but sometimes a site may have content that is viewable only if you know the direct URL, and a public API like this may make it "more public" than the developer intended. Another thing is that there may be a code-level permission check in place, and a module like this would have hard time figuring that out. That being said, have you already implemented or are you considering implementing custom selector support for such limits? I.e. allow the developer to manually define a selector that returned pages must match, or alternatively should never match? I think that could make a lot of sense from a security point of view, particularly for public API endpoints, where it might actually work best as a per-endpoint setting

Thank you very much for this module, @Nurguly Ashyrov! I missed this graphql thing completely, though was messing around json api a bit. Had some great time reading about it. Seems like ProcessWire fits graphql like a glove. Your module should answer a lot of recent questions about integrating PW with vue.js and alike. Dries Buytaert, the Drupal "godfather", has a nice article in his blog about the necessity for a contemporary CMS to have support for web-services built in. And his choice seems to be graphql and json api. I am sure that improving and promoting PW as a "headless CMS" kind of thing is something that could bring a lot of frontend developers to use PW. This module is the perfect start. As I understand, mutations are a way to not only read, but write data? If so, that is certainly worth implementing, so a complete SPA could be possible with this graphql module alone.

@adrianmak, is it just a copy&paste mistake that your code accesses $category while you set outputFormatting to false on $page? @gebeer: Additionally, there are two other methods to get a page field's value in another language (with the first one being my favorite): // 1. Directly from the page: $title_en = $category->getLanguageValue($eng, 'title'); // 2. A bit more circumspect: $titleField = $category->getUnformatted('title'); $title_en = $titleField->getLanguageValue($eng);

PW is a perfect platform for your RESTful APIs or any kind of web services. Some of my clients keep multiple sites that need to talk and share data with each other at regular intervals, and I always build "RESTful" web services with ProcessWire to accomplish this. PW was designed to make this particularly easy. But I'm not a fan of the terms "REST" or "RESTful", as I think it implies that there's something more than what it is. This is the way we were doing web services before those terms existed, and it is basically the way you would think to do it even if you never heard of it. If you are dealing with primarily GET requests (which covers most of my needs), then you don't need anything other than ProcessWire and PHP's standard file_get_contents(), json_encode() and json_decode() (or simple_xml) functions. If your needs also involve POST requests (or your PHP doesn't let you load URLs with its file functions), then I recommend grabbing the really simple and easy-to-use Snoopy class too. I don't personally bother with PUT or DELETE requests, or understand why they would be necessary or preferable over authorized GET/POST requests doing the same thing. Let me know if you'd like me to supply any simple code examples of how you might use ProcessWire in this manner.