Leaderboard

ProcessWire 3.0.136 upgrades the version of CKEditor from 4.10.1 to 4.12.1. While that might look like a minor version bump, it’s actually 5 versions ahead and includes quite a lot of new features, changes and fixes. See the CKEditor release notes for more details on all that's been added and changed in the last 5 versions. It was a year or two ago where it seemed like CKEditor was going to be phasing out CKE 4 in favor of CKE 5. But interestingly it now seems like there is a new focus in CKE 4 from the CKEditor folks, so I’m going to have to start watching the version updates more often. Of course, I remain interested in CKE 5 too, but it’s nice to see CKE 4 (my favorite editor for a long time) going so strong and getting new features and attention, which is also a nice benefit for all of us PW users. I’m looking forward to working with some of the new stuff they’ve added in recent versions as well. For instance, the autocomplete feature sounds like it has nice potential for inserting Hanna codes or links to other PW pages, among other things. Also new in 3.0.136 is a new Debug::backtrace() static method in the core. I often use PHP’s debug_backtrace() method when debugging (and it appears in PW’s fatal exceptions), but the reality is it gives me a lot of stuff I just don’t want… all the hook method calls and such that aren’t usually relevant to what I’m trying to find. So the new built in Debug::backtrace() method returns a much simpler array than PHP does, and it also excludes all of the [likely] irrelevant internal hook method calls, and is just generally more focused on what you are likely to need from a backtrace in ProcessWire. It’s very convenient to plug into a ProcessWire $wire->message(Debug::backtrace()), or a Tracy Debugger bd(Debug::backtrace()); or even an echo '<pre>' . print_r(Debug::backtrace(), true); call. Though please consider this new method a work in progress, as it’s just a start at the moment and is likely to get additional updates. At some point, PW’s fatal exceptions will likely use the output from this method as well. Since this is kind of a short post, I’m just posting in the forums rather than creating a new blog post. More core updates on the way next week. Hope you all have a great weekend!

I can relate to that. But the thing is I often do not do my html/css/js myself and pretty often people with very little knowledge of php are to make minor changes to view code. That's why I try to have my markup as close to raw html as possible. And render functions are clearly the opposite. A am with you here. Entities should not be multiplied without necessity)) And that's why I do not quite like the placeholder thing. I think it should be that generic call for controller and view. And in this specific case sidebar usually is not tied to a particular template. So this thing seems "too opinionated" for me) I even think that the whole layout thing can be moved to view folder. I now think it is more clear to keep all the view related stuff in one place (though i did use dedicated layout folder in the past - now it is inside the view folder in my recent projects).

Sounds familiar ? SAML is actually a pretty simple concept. I'm not an expert, but to summarise: LDAP is a general purpose protocol for communicating with directory services. When it comes to authentication, typically the way you'd set this up is by providing a local login form (ProcessWire's native one or something else), and when the user has provided credentials, you use the LDAP protocol to pass them to the AD server for validation, and then – depending on the reply – either log the user in (creating user object in the process if necessary), or display an error if provided credentials couldn't be validated. SAML is a SSO standard for authentication. Here the identity provider (often ADFS or Azure AD) takes on more responsibilities: in the case of SAML Auth 1) the user attempts to access the admin or other protected area, 2) the module detects this and redirects the user to the IDP's web based GUI, where 3) (unless there's already an open session) the user has to provide authentication details, after which 4) IDP redirects the user back to the site with a SAML response, and finally 5) the module either logs the user in (creating user object if one didn't exist yet) or displays an error. The reasons I personally prefer SAML is that it's an SSO solution – which means that if the user is already authenticated to the AD server they don't have to authenticate again – and that the IDP actually handles a bigger part of the process, meaning that you don't have to pass credentials to third party services, etc. That being said it doesn't really matter that much which approach you use. If the client has a backend capable of using SAML, I'd recommend that, but if not then LDAP is a decent fallback. To be honest I'm not really familiar with the service layer, but most commonly you'll find some Microsoft product from the other end. If there's ADFS (Active Directory Federation Services), it should support SAML. On the other hand if the client is using Azure AD, there's actually no LDAP support at all (unless they also use Azure AD DS), so in this case SAML might be your only option.

I've spent the last while experimenting with srcset implementation - and PageimageSrcset is the result: PageimageSrcset Provides configurable srcset and sizes properties/methods for Pageimage. Overview The main purpose of this module is to make srcset implementation as simple as possible in your template code. It does not handle images rendered in CKEditor or similar fields. For an introduction to srcset and sizes, please read this Mozilla article about responsive images. Pageimage::srcset() // The property, which uses the set rules in the module configuration $srcset = $image->srcset; // A method call, using a set rules string // Delimiting with a newline (\n) would also work, but not as readable $srcset = $image->srcset("320, 480, 640x480 768w, 1240, 2048 2x"); // The same as above but using an indexed/sequential array $srcset = $image->srcset([ "320", "480", "640x480 768w", "1240", "2048 2x", ]); // The same as above but using an associative array // No rule checking is performed $srcset = $image->srcset([ "320w" => [320], "480w" => [480], "768w" => [640, 480], "1240w" => [1240], "2x" => [2048], ]); // Use the default set rules with portrait images generated for mobile/tablet devices $srcset = $image->srcset(true); // Return the srcset using all arguments $srcset = $image->srcset("320, 480, 640x480 768w, 1240, 2048 2x", [ "portrait" => "320, 640", ]); // The set rules above are a demonstration, not a recommendation! Image variations are only created for set rules which require a smaller image than the Pageimage itself. On large sites this may still result in a lot of images being generated. If you have limited storage, please use this module wisely. Portrait Mode In many situations, the ratio of the image does not need to change at different screen sizes. However, images that cover the entire viewport are an exception to this and are often the ones that benefit most from srcset implementation. The main problem with cover images is that they need to display landscape on desktop devices and portrait when this orientation is used on mobile and tablet devices. You can automatically generate portrait images by enabling portrait mode. It is recommended that you use this in combination with Pageimage::focus() so that the portrait variations retain the correct subject. The generated variations are HiDPI/Retina versions. Their height is determined by the portrait ratio (e.g. 9:16). Variations are always generated, regardless of whether the original image is smaller. Upscaling is disabled though, so you may find that some variations are actually smaller than they say they are in their filename. The sizes attribute should be used when portrait mode is enabled. Pageimage::sizes will return (orientation: portrait) and (max-width: {maxWidth}px) 50vw by default, which handles the use of these images for retina devices. The maximum width used in this rule is the largest set width. Pageimage::sizes() There is no option to configure default sizes because in most cases 100vw is all you need, and you do not need to output this anyway as it is inferred when using the srcset attribute. You can use the method for custom sizes though: // The property $sizes = $image->sizes; // Returns 100vw in most cases // Returns '(orientation: portrait) and (max-width: {maxWidth}px)50vw' if portrait mode enabled // A method call, using a mixture of integer widths and media query rules // Integer widths are treated as a min-width media query rule $sizes = $image->sizes([ 480 => 50, "(orientation: portrait) and (max-width: 640px)" => 100, 960 => 25, ]); // (min-width: 480px) 50vw, (orientation: portrait) and (max-width: 640px) 100vw, (min-width: 960px) 25vw // Determine widths by UIkit 'child-width' classes $sizes = $image->sizes([ "uk-child-width-1-2@s", "uk-child-width-1-3@l", ]); // (min-width: 640px) 50vw, (min-width: 1200px) 33.33vw // Determine widths by UIkit 'width' classes $sizes = $image->sizes([ "uk-width-1-2@m", "uk-width-1-3@xl", ]); // (min-width: 960px) 50vw, (min-width: 1600px) 33.33vw // Return the portrait size rule $sizes = $image->sizes(true); // (orientation: portrait) and (max-width: {maxWidth}px) 50vw // The arguments above are a demonstration, not a recommendation! Pageimage::render() This module extends the options available to this method with: srcset: When the module is installed, this will always be added, unless set to false. Any values in the formats described above can be passed. sizes: Only used if specified. Any values in the formats described above can be passed. uk-img: If passed, as either true or as a valid uk-img value, then this attribute will be added. The srcset attribute will also become data-srcset. Please refer to the API Reference for more information about this method. // Render an image using the default set rules echo $image->render(); // <img src='image.jpg' alt='' srcset='{default set rules}'> // Render an image using custom set rules echo $image->render(["srcset" => "480, 1240x640"]); // <img src='image.jpg' alt='' srcset='image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w'> // Render an image using custom set rules and sizes // Also use the `markup` argument echo $image->render("<img class='image' src='{url}' alt='Image'>", [ "srcset" => "480, 1240", "sizes" => [1240 => 50], ]); // <img class='image' src='image.jpg' alt='Image' srcset='image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w' sizes='(min-width: 1240px) 50vw'> // Render an image using custom set rules and sizes // Enable uk-img echo $image->render([ "srcset" => "480, 1240", "sizes" => ["uk-child-width-1-2@m"], "uk-img" => true, ]); // <img src='image.jpg' alt='' data-uk-img data-srcset='image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w' sizes='(min-width: 960px) 50vw'> // Render an image using portrait mode // Default rule sets used: 320, 640, 768, 1024, 1366, 1600 // Portrait widths used: 320, 640, 768 // Original image is 1000px wide // Not possible to use portrait mode and custom sets or portrait widths in render() // Sizes attribute automatically added echo $image->render(["srcset" => true]); // <img src='image.jpg' alt='' srcset='image.320x569-srcset-hidpi.jpg 320w, image.640x1138-srcset-hidpi.jpg 640w, image.768x1365-srcset-hidpi.jpg 768w, image.jpg 1024w' sizes='(orientation: portrait) and (max-width: 768px) 50vw'> Configuration To configure this module, go to Modules > Configure > PageimageSrcset. Set Rules These are the default set rules that will be used when none are specified, e.g. when calling the property: $image->srcset. Each set rule should be entered on a new line, in the format {width}x{height} {inherentwidth}w|{resolution}x. Not all arguments are required - you will probably find that specifying the width is sufficient for most cases. Here's a few examples of valid set rules and the sets they generate: Set Rule Set Generated Arguments Used 320 image.320x0-srcset.jpg 320w {width} 480x540 image.480x540-srcset.jpg 480w {width}x{height} 640x480 768w image.640x480-srcset.jpg 768w {width}x{height} {inherentwidth}w 2048 2x image.2048x0-srcset.jpg 2x {width} {resolution}x How you configure your rules is dependent on the needs of the site you are developing; there are no prescriptive rules that will meet the needs of most situations. This article gives a good overview of some of the things to consider. When you save your rules, a preview of the sets generated and an equivalent method call will be displayed to the right. Invalid rules will not be used, and you will be notified of this. Portrait Mode Set Widths A comma limited list of widths to create HiDPI/Retina portrait variations for. Crop Ratio The portrait ratio that should be used to crop the image. The default of 9:16 should be fine for most circumstances as this is the standard portrait ratio of most devices. However, you can specify something different if you want. If you add a landscape ratio, it will be switched to portrait when used. Any crops in the set rules ({width}x{height}) are ignored for portrait mode variations as this ratio is used instead. UIkit Widths If your website theme uses UIkit, you can pass an array of UIkit width classes to Pageimage::sizes to be converted to sizes. The values stored here are used to do this. If you have customised the breakpoints on your theme, you should also customise them here. Please note that only 1- widths are evaluated by Pageimage::sizes, e.g. uk-width-2-3 will not work. Remove Variations If checked, the image variations generated by this module are cleared on Submit. On large sites, this may take a while. It makes sense to run this after you have made changes to the set rules. Image Suffix You will see this field when Remove Variations is checked. The value is appended to the name of the images generated by this module and is used to identify variations. You should not encounter any issues with the default suffix, but if you find that it conflicts with any other functionality on your site, you can set a custom suffix instead. Debug Mode When this is enabled, a range of information is logged to pageimage-srcset. PageimageSrcsetDebug.js is also added to the <head> of your HTML pages. This will console.log a range of information about the images and nodes using srcset on your page after a window.onresize event is triggered. This can assist you in debugging your implementation. The browser will always use the highest resolution image it has loaded or has cached. You may need to disable browser caching to determine whether your set rules are working, and it makes sense to work from a small screen size and up. If you do it the other way, the browser is going to continue to use the higher resolution image it loaded first. UIkit Features This module implements some additional features that are tailored towards UIkit being used as the front-end theme framework, but this is not required to use the module. Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. ProcessWire >= 3.0.123 is required to use this module.

When your blog content is growing to some thousands of pages and you have comments scattered here and there, sometimes you start wondering if placing comments below each post is the best approach. Of course this totally depends on your project and contents. In my case I came to the conclusion I could provide a better user experience switching to a Forum-like solution, where discussions were organized by macro subjects and not below each individual post. Of course there are many products and services providing fully featured forum solutions, but getting only few comments per day I was reluctant to setup a dedicated forum and to deal with users' profiles. A nice thing of the comments system is that users do not need to create account and password, but simply use their email address. And here we are ... why not to setup a very basic Forum-like solution using PW Comments? But please do not get too excited… we will just use comments in a way that looks-like-a-forum. I think this solution makes sense if you have a limited number of comments per day spread on some topics. If you need to deal with high discussions traffic with several users ... do it with a fully featured forum solution !! To implement this Forum-like solution we will take benefits of (1) PW pages/templates flexibility (why you should be here otherwise…), (2) core module FieldtypeComments, (3) Uikit 3 Site/Blog Profile, (4) some of the tutorials I recently released about PW Comments (listed at the end). OK, let's start. Login into the Admin panel, select Setup, and then Fields. Let's create a checkbox field named "sticky" that we can use to keep some forum subjects on top of the communities. Now let's move to Setup, Template. We will create a new template with name "communities'. In addition to "title" field, we will add also "body" and "sidebarRight" fields (already available in the profile): Then we create a template, that we will use for individual communities, with name "community". In addition to "title" field, we will add "date", "body", "images", "comments" fields (already available in the profile) and the "sticky" field we have just created. If you wish, as I did, you can also associate some category fields. If you use Multi-Language is a good idea to use the field "date", as ,differently from createdStr, it will automatically return a locale-formatted date as you defined in the field. Now that we have created the templates, we need to customize them. Reopen the "communities" template. In the Family tab: allow the template to have children, allow only one page with this template, select "community" as only allowed template for CHILDREN. Then in the URLs tab: select allow page numbers. This will return a paginated list of communities. We reopen the "community" template. In the Family tab: do not allow the template to have children, allow to create new pages, select "communities" as only allowed template for PARENT. Now in the URLs tab: select allow page numbers. This will be necessary to create paginated comments. Let's go to the page-tree, under Home we will create a new page named "Community" using the templates "communities" (note the final s), this will be the page listing all the communities. Under the Community page, we will create the individual communities. Give the pages the name you wish and use the template "community" (note w/o the final s). It may be good creating one with the name "New Forum Requests" checking its "sticky" field so that it remains on top. As to implement this Forum-like solution, the comments pagination is a must, at this stage you will have to implement it as described in this tutorial: Now we are ready for coding (very little!) the php templates. We need to associate php files to the two templates we have created. In site/templates create two new php files communities.php and community.php. Open the template blog.php and copy its content to communities.php, then repeat the same operation copying the content of template blog-post.php to community.php. Great! We are few steps away from our Forum-like solution. Modify communities.php as follows: ... echo ukHeading1(page()->title, 'divider'); echo page()->body . '<br><hr>'; //>>>>> ADD THIS LINE //$posts = page()->children('limit=10'); //echo ukBlogPosts($posts); $posts = page()->children('sort=-sticky, sort=title, limit=10'); //>>>>> ADD THIS LINE echo ukBlogPosts($posts, ['moreText' => '', 'moreIcon' => '']); //>>>>> ADD THIS LINE ... Then modify community.php as follows: // blog post content echo ukBlogPost(page()); // comments if($page->hasField('comments')) { //>>>>> ADD THIS LINE $comments = page()->comments; // comment list if(count($comments)) { //echo ukHeading3("Comments", "icon=comments"); echo ukComments($comments->find("sort=-created"), ['paginate' => true]); //>>>>> ADD THIS LINE - READ PAGINATION TUTORIAL (NEEDED) echo '<hr>'; } // comment form $gdpr = __('I agree with the processing of my personal data. I have read and accept the Privacy Policy.'); //>>>>> ADD THIS LINE - READ GDPR TUTORIAL (OPTIONAL) echo ukHeading3(__('Join the discussion'), "icon=comment"); echo ukCommentForm($comments, ['labels' => ['gdpr' => $gdpr]]); //>>>>> ADD THIS LINE - READ GDPR TUTORIAL (OPTIONAL) } //>>>>> ADD THIS LINE Very good (hope so...). Now let's see the result. When browsing to the Community page we will get the list of the communities. In my example I decided to keep sticky the one where users can submit suggestions for new forum subjects. Selecting one of the communities we have created, we are going to see (1) a description of the community, (2) a paginated list of comments, (3) and the comment form at the bottom. Please note that in this picture pagination is kept with a limit of three items just to fit the image … It makes sense to have 10-15-20 comments per page depending on your preferences. And we are done, here it is. If you wish you can implement some additional features as described in the tutorials below. Not mandatory but probably makes good sense to enable the honeypot field as described in this tutorial as anti-spam measure: If you have the "pleasure" to deal with GDPR matters, here is described how to add a privacy checkbox to your comment form: and finally if you wish your Forum-like solution to be Multi-Language here it is what to do: I hope you enjoyed and wish you a nice week-end ! PS: it's a couple of tutorials I miss the emoj … hope they will come back in this forum soon !!

This week I was catching up with client work after traveling last week, but some of that work overlapped with a focus on WireMail modules. As a result, this week I’ve released two new WireMail modules, and also have information in this blog post on how you can configure two existing WireMail modules (WireMailSmtp and WireMailPHPMailer) to use Gmail as the SMTP sender— https://processwire.com/blog/posts/wiremail-modules-and-gmail/

That changes things quite a bit. Personally I've never been a part of this kind of team – as strange as it may sound, I've worked in teams where there are backend developers and so-called full-stack developers, but never a "pure" front-end developer ? You've definitely given me something to think about here! Features that are not tied to a specific template have in my use cases usually been partials with very little "logic" behind them, but this would actually be a nice use case for shared (sub)controllers as well, which is something I'll likely dive into soon. Basically the idea is to have a controller that isn't tied to a single template, but rather can be used by multiple templates. Also controllers that inherit other controllers – "base controllers", or whatever they might be called – is another way to achieve shared features. Overall there's a lot you can do with current codebase, but since there are different use cases, it's very much about finding a balance between "not opinionated enough" and "too opinionated" ? As for layouts, I've found the concept really useful, and since I use them in pretty much all projects I work on, this is something I wanted to have built-in and ready-to-use within Wireframe. Placeholders are a key part of this, as they provide an easy way to embed views (of which there may be one or more for each specific template) within commonly shared layouts –aAnd because layouts serve a different purpose from view files (individual views for templates) and partials (smaller pieces of content intended to be embedded within layouts or view files), I've opted to store them separately. This is again one of those cases where it's all about finding the right balance and figuring out what should be available out of the box and what to leave for individual developers to figure out on their own, and I feel that current split between layouts/views/partials is a reasonable one – but because I know there are different opinions, much of this is actually already configurable. Also, since layouts are optional, one can always opt out from using them ?

@teppo I was using Pete's Markup Sitemap XML, but apparently it has some bugs. I've installed Mike's Markup Sitemap module and it seems to have resolved the issues I was experiencing. I wish it had support for the image license, but otherwise feels like a nice update. Edit: Looks like it does support image license. Edit 2: But unfortunately it doesn't look like the image license is working correctly. I've reported the issue in that module's support thread:

@elabx Thanks for idea. $repeater_fields = $this->wire('fields')->get('builder')->repeaterFields; $text_based_fields = $this->wire('fields')->find("id=" . implode($repeater_fields, '|') . ', type=FieldtypeTextarea|FieldtypeText|FieldtypeTextareaLanguage|FieldtypeTextareaLanguage'); $search_fields = $text_based_fields->implode('|', 'name'); $page->builder->find("{$search_fields}!=''")->each(function ($item) use (&$content, $search_fields) { $content .= $item->get($search_fields); }); Now I need to get it work with different langauges.

What about finding the fields first? $textFields = $fields->find('type=FieldtypeTextarea|FieldtypeText') $page->builder->find("$textFields!=''")->each(function ($item) use (&$content, $sanitizer) { $content .= $item->get(...); }); EDIT: Oh just read again about "text extended fields". This obviously won't work :/ Maybe: $textExtendedFields = []; $fields->each(function($f){ if(wireInstanceOf($f->type, "FieldtypeText") === true) { $textExtendedFields[] = $f; }; })

haha. obviously.... the wrong question... yes ?‍♂️ Thanks a lot for pointing me into the right direction

I get your point, and agree – to a point. When I first came across the idea of render functions (with that specific name it was some bit of code from Ryan I believe), this was exactly what I thought ? Since then I've used render-functions in numerous projects, and while in some cases it still feels a bit "dirty", in real world it can be a tremendously helpful strategy and hasn't really caused me any notable headaches so far – quite the opposite. These days I don't have a major issue with code that generates markup as long as it's clearly separated into its own container, i.e. "siloed" properly. While I don't encourage mixing business logic with presentation, this is one of those cases where the line is a bit blurry. Also, as a minor note I don't think that we should separate logic and presentation based on the language alone. PHP can be used to create "presentational" content, so overall it's more about what you do than how you do it. Something like Twig is supposed to be "purely presentational", but you wouldn't believe the complexity of some of the logic I've seen implemented in/with it. (But this is a topic for another discussion – templating languages vs. using PHP as a templating language, and so on and so forth.) Awesome! As far as I can tell this is actually really close to this rough idea I mentioned earlier – or, more precisely, it would be one possible use case for (or variation of) it: > Another idea I've been toying with would be subcontrollers (or child controllers, or partial controllers, or whatever terminology makes most sense) I'm not entirely sure if it actually needs to be a separate concept ("chunks", or whatever that would be called), but that's not necessarily a bad idea, if it makes the concept easier to grasp. Technically it should already be possible to instantiate a new Controller, provide it with a View file, and then render the output within, say, another Controller. That's what Wireframe itself does for the page, though it all happens automatically. Another thing that might not be obvious yet (I'll have to check the docs relating to this) is that there are two use cases for views: They provide alternative ways to render a Page. For an example the default view might render markup (HTML) for the entire page, and another might render an RSS feed for a list of news items. They can be used to populate View Placeholders: if you request <?= $placeholders->aside ?> in a layout file used for the "home" template and add a view file at views/home/aside.php, Wireframe will automatically populate the "aside" placeholder with the content of current page rendered with that view file. Anyway, I'll definitely dig into this topic a bit more and come back with some sort of solution, hopefully – thanks for linking to the TemplateEngineFactory example ? Thanks – this list was quite helpful. For the record, here's how I've handled these examples in my past projects: For menus I've used MarkupSimpleNavigation, and later MarkupMenu. In the boilerplate profile I do have partials for these, but they just call the render function of a markup module. Breadcrumbs is in my case usually a simple list of parents, thus I've used a "dumb" partial file with a foreach loop. Here's an example. Sidebar, again, tends to be either a single RTE field (something like sidebar, aside, or perhaps right_column or left_column), or sometimes a predefined list of multiple fields. Again a valid use case for so-called dumb partial files, but this is actually exactly the use case for which I originally added the ability to use View files as View Placeholders. Repeating elements covers a wide area of different content, but in my projects these have usually meant one of two things: A news list or something similar, with predefined header, list of items, and often some sort of "footer" area as well. These use cases I've usually solved with render functions. Repeater, RepeaterMatrix, or some other repeatable fieldtype. "Dumb" partials with some foreach rules, or native field rendering (particularly useful for RepeaterMatrix). Note that I'm not saying that your use cases are invalid, or that the list above would be the "correct" way to handle these. It's just that I can see why this hasn't been a notable issue for me – but this also helps me understand the kind of use cases you've run into, and thus figure out how to continue from here on ?

I'd first look into setting up SAML integration. Overall I think that a SAML powered SSO solution is always easier and more user-friendly approach. SAML Auth handles this quite nicely, though it may take a bit of configuring to get everything right, and it also looks like the module hasn't been updated in a couple of years – so I'd first make sure that there are no issues with the bundled OneLogin's SAML PHP Toolkit. ... and if there are, perhaps you could try updating it and submitting a pull request? ? There are some LDAP modules as well, and I actually have one just sitting on my local machine that I'd really like to share. It's a module I built in my last job for a client project, and I know it's powering at least one production site already, but I just haven't had the time to add the last finishing touches on it yet. Also, I don't really have a need for LDAP stuff in my personal projects, so there's that ? Anyway, I can't give a specific timeframe but I'll make a note to get the module finished and published.

Hey @VeiJari, thanks for your report ? Those warnings were fixed in version 0.5.1 – I keep forgetting that core classes don't use strong typing for non-object parameter values. Lesson learned: always develop with debug mode on (or use something else to display all warnings). "Indexed 0 pages in 0 seconds" isn't related to the warnings. This just means that the module couldn't find pages with your configured search index field. I've added a warning message for this situation, explaining what happened and what to check first (that your index field is actually added to at least one template with existing pages), but other than that I'd have to know a bit more about your specific setup to answer why this is happening. Additionally (with latest release 0.6.0) I've changed the defaults so that any non-trashed page with the index field is now automatically included. Previously the default selector for this feature only included public pages, which meant that hidden and/or unpublished pages were not indexed (via the "Index pages now?" feature, that is – saving the page itself indexed it as expected). -- If you're still getting a message that indexable pages couldn't be found, please let me know how you've configured the module, and which version of ProcessWire you're using. Also please make sure that you actually have indexable pages to begin with – unless you've specified a selector string for the "Index pages now?" feature, this is the selector that finds those pages for you ?

Great design, minimal, clean. I guess I have been following your work since I started using PW. :)

Here's a little text formatter module that redirects all external links found in a textarea (e.g. for hit counting) to a given URL. TextformatterExternalRedirect GitHub repo As TextFormatters do, this module modifies the contents of the textarea (HTML) at rendering time. It prepends the given URL to the link address for external links (http and https), optionally makes sure that the link is opened in a new window and allows you to add css classes to such links. All options can be configured in the module's configuration settings. Usage: Download the zip archive and extract it to site/modules, the rename the top folder to TextformatterExternalRedirect Go to the backend and select "Modules" -> "Refresh", then click "Install" for "External Link Redirect" Click "Settings" and configure the module Go into the field configuration for the field(s) you want this formatter to apply to and add it from the dropdown Done, now any external links in the configured fields will have the configured settings applied Feel free to leave feedback and post and questions you have here.

I'm going to relate this to PW, promise. I'm looking for a cool, simple, free helpdesk system. Nothing too fancy, just letting users in, post a ticket, get replies, talk back, close ticket, reopen ticket, close again. See a list of what was requested, what's open, what's done. Anyone got suggestions? I can only find paid or crap solutions. No middle ground. Now the link to PW: As a way to promote PW, would it be a good idea if we had projects, like a ticket system, free and based on PW? You'll all probably agree it would be relatively easy to pull off a ticket system in PW. I'm imagining something styled by the theme system (I love Reno), using an installation profile to setup, the roles system that's already there, and sold as "the free, processwire powered helpdesk system". Devs need ticket systems and like me want to avoid spending a dime. They find this and try it out. It's cool. Let's have a look at PW since we're here. Whoa this is awesome! And my clients will see the same beautiful, tidy interface on their CMS? Screw you WP, I'm going PW from now on! Does this sound like a good idea or am I just trippin?

similar here ? really old... but it works ^^

This one's not really new, but I forgot to post about it when I did it, plus there are still some unfinished aspects. I have a minimal personal invoice setup allowing me to have multiple identities for my invoices, to represent the different aspects of what I do (it's not all PW)... The child pages of an identity represent permissible payment methods for that identity... Of course, there are multiple clients under which invoice pages are stored, with highlighted status in the page tree... Invoices use repeater fields to store line-items and expenses. The line subtotal is calculated on save. The whole invoice value is worked out too. Profit and Loss is yet to be finished. And here's the result... I like PW!

You can double-click the bin icon on file/image fields to mark all items for deletion.

You can use a hook to append a formatted created date to the end of the page list label. In /site/ready.php... $this->addHookAfter('ProcessPageListRender::getPageLabel', function($event) { $page = $event->arguments('page'); $created = date('d/m/y', $page->created); $event->return .= " $created"; });