Leaderboard

A feature request here in the forums prompted me to shape a piece of code I had been tinkering with into a usable module. Template Parents What it does: The list of possible templates for new pages in ProcessWire is purely based on other templates in parent/child relationships managed in the involved templates' family settings. This is most often okay, but sometimes you want to limit creation of pages with a certain templates to individual spots in the page tree, and there's no clear parent/child relationship to go with. The initially quick solution would be to duplicate parent templates for the different spots, but then any change on one of these templates has to be made to the others too, which gets tedious and error prone. Template Parents adds an entry in the Setup menu where you can assign allowed parent pages to templates. These rules are enforced after the regular family settings have been executed, so it builds upon instead of replacing PW's built-in mechanism. There's also an option in ProcessTemplateParents' to enable inheritance, then entries in the Template Parents assignment are inherited down the page tree and also grant template permissions to children, grandchildren and so on. The module can be downloaded from the GitHub repository. It has been tested with PW 2.7 and 3.0.

@Ivan: A good idea. In fact, the one I initially had in mind, but I somehow got it into my head to save the settings directly with the template configuration which I couldn't. Of course, one thing doesn't necessitate the other and I can both hook into ProcessTemplate and use my own database table. So, version 0.0.6 is on GitHub and does allow that.

You mean something like this?

You would have to do it either manually or using the API. If it's only a few pages to deal with you could do it manually. Otherwise, use the API. Something like this. First, rename your current text field 'views_count' to something like 'views_count_old' Create an integer field called 'views_count'. Add it to your template (the one with pages requiring view counts) Backup your db Run the code below in a template file (doesn't matter which one) on a test install first if you can. If all goes well, run on your 'real' install If all went well, remove 'views_count_old' from the above template @note: Written in browser and haven't tested but it should work. If you have thousands of pages you will want to do it in batches foreach ($pages->find('template=template-with-views-count-field') as $p) { $p->of(false); $p->views_count = (int) $p->views_count_old; $p->save('views_count'); }

Take a look here - quite a similar topic. Thought pwired has listed some newer (and quite usefull) additions to the module directory, which deserve their way into your toolbox.

Why do you want to do this ? Inline css lowers the security and breaks the consistency of the website. In CKEditor you should not go any further as allowing html tags but keep the css inside your templates folder. Anyway: Admin => Setup => Fields => Your field => Input scroll down to Format Tags and add div to it: div;p;h2;h 3;h4;h5;h6;pre;address scroll down to Extra Allowed Content and add wildcards for the <a> and <div> tag: a[*]{*}(*) div[*]{*}(*) Now your <a> and <div> tags won't be stripped off anymore. The CKEditor forced <p> tags are still wrapped around your html tags, this is how you can get rid of them: (body field example) Open config-body.js in your Editor (site\modules\InputfieldCKEditor\config-body.js) and make it look like this, to prevent the forced <p> tags: CKEDITOR.editorConfig = function( config ) { // Define changes to default configuration here. For example: // config.uiColor = '#AADC6E'; config.enterMode = 2; config.shiftenterMode = 1; }; Now you have your html tags free from wrapped <p> tags.

Great thing! And your reaction speed to forum requests is fascinating! I guess it might not be too hard to integrate this into the template family tab. This way working with parent/child relationships would be easier - you do not have to go to 2 different screens for that. What do you think?

Haven't tested it in 3.x yet, but I'm about to. Update: tested with 3.x and worked like a charm.

I'd say that it's definitely about blocks: concrete5 makes it quite easy to create unique page structures on the fly. It's not like we couldn't do something similar with ProcessWire, but in the case of concrete5 it's a built-in, original core concept, and thus it's no surprise that they excel in this area. Some of their UI's still look really ugly and amateurish, but putting that aside, it's a great product in many ways. That being said, personally I'm not such a huge fan of this strategy. I'll admit that it does empower the content editor and give them a lot of sway on the way the site looks, but that's actually a double-edged sword: sometimes it works out just fine, but sometimes the site ends up being a total mess. Especially for sites with a bunch of content editors and a lot of content, a well planned structure and information architecture is a must I remember looking into concrete5 a few years ago, the main reason being the way they handle page blocks. Their concept is nearly identical with our old in-house CMS (page blocks, content areas, all of that) and when we decided to move on, concrete5 seemed like the obvious choice. For various reasons we ended up with ProcessWire instead, and I'm glad we did.

MediaLibrary Update: MediaLibrary can now be found in the official module list. Out of necessity, I've started to implement a simple media library module. The basic mechanism is that it adds a MediaLibrary template with file and image fields. Pages of this type can be added anywhere in the page tree. The link and image pickers in CKEditor are extended to allow quick selection of library pages from dropdowns. In the link picker this happens in the MediaLibrary tab, where you can also see a preview of the selected image. In the image picker, simply select a library from the dropdown at the top, everything else is handled by standard functionality. I've put the code onto github. This module is compatible with ProcessWire 3. Steps to usage: Download the module's zip from github (switch to the pw3 branche beforehand if you want to test on PW 3.x) and unpack it into site/modules Click "Modules" -> "Refresh" in the admin Click "Install" for MediaLibrary For testing, create a page with the MediaLibrary template under home (give it an expressive title like 'Global Media') and add some images and files Edit a differnt page with a CKEditor field and add a link and an image to see the MediaLibrary features in action (see the screencap for details) Optionally, go into the module settings for MediaLibrary Note: this module is far from being as elaborate as Kongondo's Media Manager (and doesn't plan to be). If you need a feature-rich solution for integrated media management, give it a look. Feel free to change the settings for MediaFiles and MediaImages fields, just keep the type as multiple. There are some not-so-pretty hacks for creating and inserting the correct markup, which could probably be changed to use standard input fields, though I'm a bit at a loss right now how to get it to work. I've also still got to take a look at error handling before I can call it fit for production. All feedback and pointers are appreciated (that's also why I post this in the development section). Edit 09.03.2016 / version 0.0.4: there's now also a "Media" admin page with a shortcut to quickly add a new library. Edit 01.05.2016: Version 0.0.8: - The module now supports nested media libraries (all descendants of eligible media libraries are also selectable in link/image picker). - There's a MediaLibrary::getPageMediaLibraries method you can hook after to modify the array of available libraries. - You can switch between (default) select dropdowns or radio boxes in the module configuration of MediaLIbrary to choose libraries. Edit 10.10.2018: Version 0.1.3: - Dropped compatibility for ProcessWire legacy versions by adding namespaces - Allow deletion of libraries from the Media overview admin page - Added an option to hide media libraries from the page tree (optionally also for superusers)

ProcessWire 3.0.12 now supports the ability to use extended (UTF-8) page names, meaning your URLs can now have just about any characters that you want… https://processwire.com/blog/posts/hello-健康長壽·繁榮昌盛

https://github.com/gRegorLove/ProcessWire-IndieAuth This module allow users to sign in to your site using IndieAuth: IndieAuth is a way to use your own domain name to sign in to websites. It works by linking your website to one or more authentication providers such as Twitter or Google, then entering your domain name in the login form on websites that support IndieAuth. This module has two different functions: IndieAuth Authentication After a user enters their domain name and successfully authenticates, they will be redirected back to your site and the session variable indieauth_domain will be set. You can then use this session variable to customize your site for the user or offer additional functionality. Note: The user is not logged in to ProcessWire at this point. ProcessWire Authentication If you would like to allow users to log in to ProcessWire using IndieAuth, you will need to make a few changes to the user profile. Add a field named website Add that field to the user template Update the User Profile module to make the website field user-editable The user will need to set their domain name in their user profile before they can log in with IndieAuth. Setup After installing the module, copy the template file extra/templates/indieauth.php into your site/templates/ directory. In the admin area, add the new indieauth template. On the "URLs" tab for the template, check "HTTPS only." Create and publish a new ProcessWire page using this template, e.g. https://example.com/auth/ The included template is a minimal, sample template that covers both of the functionalities described above. You can expand the template or integrate it into your existing templates as needed. For more information about the sign-in form and how the verification works, please refer to https://indieauth.com/developers Notes This module does not create user records if they do not exist already.

Processwire already has all core functionality to begin with. It's decoupled and api first, leaving it up to you what you want to build. To answer the question I could think of modules like hanna code, ImageMagick, TracyDebugger. http://modules.processwire.com/modules/process-hanna-code/ https://processwire.com/blog/posts/processwire-3.0.10-expands-image-resize-options/ http://modules.processwire.com/modules/tracy-debugger/

Another way could be to build and use an independent module and hook into after ImageSizer::resize instead building a (redundant) copy of a imagesizer engine module. Advantages: it will work with every (different) invoked imagesizer engine/s, and not only with the custom modified one! <?php namespace ProcessWire; class ImagesizerWithNginx extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Imagesizer with Nginx-Cluster', 'version' => 1, 'summary' => "", 'author' => "", 'autoload' => true, 'singular' => true ); } public function init() { $this->pages->addHookAfter('ImageSizer::resize', $this, 'uploadToNginx'); // Fired when a new or updated variation is created $this->addHookAfter('Pagefiles::delete', $this, 'deleteNginxfile'); // Fired when a file is deleted from a page } public function uploadToNginx($event) { $image = $event->object->image; $pageID = $image->page->id; $filename = $event->object->filename; $extension = $event->object->extension; // optionally optimize the image bfore upload, and then ... upload image to target } public function deleteNginxfile($event) { // see the S3 module } }

Given the following: you never show original images to the visitors, (what I highly recommend, as of the original should be in 100% quality, what would be much to high filesizes) every image variation is created through pageimage (= is a (new) imagesizer engine) it is possible to define a .htaccess directive for redirecting to the /site/assets/files/{ID}/{IMAGES} It should be possible to clone and modify one of the new Imagesizer Engines in that way, that you transport a copy of each created variation to the nginx cluster here in the image engine. Then the only other thing you need is a hook into Pagefiles::delete! So, you would need a module like this <?php namespace ProcessWire; class ImageSizerEngineIMagickNginx extends ImageSizerEngineIMagick { public static function getModuleInfo() { return array( 'title' => 'IMagick Image Sizer with nginx-Cluster', 'version' => 1, 'summary' => "Upgrades image manipulations to use PHP's ImageMagick library when possible.", 'author' => '', 'autoload' => false, 'singular' => false, ); } public function init() { $this->addHookAfter('Pagefiles::delete', $this, 'deleteNginxfile'); // Fired when a file is deleted from a page } // a complete copy of the original method, with addition of a call to the upload method as shown above, (line 342) protected function processResize($srcFilename, $dstFilename, $fullWidth, $fullHeight, $finalWidth, $finalHeight) { ... uploadToNginx($dstFilename); ... } public function uploadToNginx($imagefile) { // get the page id for the assets subfolder and get the basename of the $imagefile to build the target ... upload $imagefile to target } public function deleteNginxfile() { // see the S3 module } } PS: I would process the variations with 100% quality and pass the variations through an image optimizer like jpegoptim, just before you have to upload it. But I think that this is on your todo already.

Assuming that each user should have access only to his own account/ content, there is no need to work with UrlSegments since you have access to the $user API. The output of example.org/dashboard/ can be individually to each user. Example: Create a role 'frontenduserrole' without any permission. Create a template dashboard and a file dashboard.php like if ($user->isLoggedin() && $user->hasRole('frontenduserrole')) { echo "Welcome back $user->name"; } else echo "You need to login first.";

I put up your code and set some outputs to it with no result in the end. $customUserRoles = $roles->find( "name^=member-" ); echo $customUserRoles->first()->name; // output: member-gold (OK) echo count($customUserRoles); // output: 2 (OK) $profileTemp = $users->find( "roles=$customUserRoles" ); echo count($profileTemp); // output: 2 (OK) echo $profilesTemp->first()->name; // output: "" (nothing, not OK) It seems as a guest I can get some information but not filtered with roles (even with "check_access=0" or "include=all"). Another test was also successful, as long as I do not use "roles": $profilesTemp = $users->find( "name^=a" ); // find user beginning with "a" in the name echo count($profilesTemp); // output: 1 (OK) echo $profilesTemp->first()->name; // output: "adam-..." (OK) $profilesTemp = $users->find( "user_firstname^=a" ); // find user beginning with "a" in the field user_firstname echo count($profilesTemp); // output: 1 (OK) echo $profilesTemp->first()->user_firstname; // output: "Adam" (OK) Edit: Thank you LostKobrakai, that's it! It worked out like it should and is displaying on the page. Will do that with the other pages after some food input!

Here's a short module that adapts href and src links in CKEditor fields when a page is cloned: ProcessPageCloneAdaptUrls Normally, href links and image urls still point to the original page's assets folder when you copy (clone) a page. This module hooks into Pages::cloned and adapts all src and href attributes found in HTML tags that point to the old assets directory, rewriting them to link to the copy's assets. This module was motivated by a feature request (#1687) on PW's github tracker. Requires: ProcessPageClone (Core, but not installed by default) Status: beta Download: git repo Module directory Feedback: welcome!