Leaderboard

Would it be useful to any other module authors if there were some way of notifying a module that it had just been updated? So, when you do a module update in the core, to have an OnVersionChange($old, $new) method (or something else that hits the mark) in the base class that the core then calls. Modules could override the implementation to provide whatever udpate to their schemas they need? I know that some of Teppo's modules track their version numbers so they can detect changes and update their table schemas as needed but it seems to me that this would make a pretty good core-feature candidate. I've just had a most welcome pull request on one of my older modules but it will require me to manually add my own module version checking/schema update mechanism to handle things nicely (probably just a copy of the way Teppo does it) but I'd rather not do that if we can get something into the core that does it well.

Another significant update which should be a huge timesaver. You can now populate all the text/numeric fields on newly created child pages (Add & Overwrite modes) from CSV formatted rows. This allows easy creation and population of all page content, for example you could populate an entire page tree of country details by pasting in CSV formatted content like: "Bolivia, Plurinational State of",BO,"BOLIVIA, PLURINATIONAL STATE OF",BOL,68 "Bonaire, Saint Eustatius and Saba",BQ,"BONAIRE, SAINT EUSTATIUS AND SABA",BES,535 etc etc Hope you guys will find this as useful as I am As always, let me know if you have any problems or suggestions for improvements!

last update switched from Mysqli to PDO all Inputfields available in all PW versions 2.5.0 and higher (Radios and Checkboxes incl.) Filter added

Whoops. My fault entirely. I didn't type what I thought I'd typed and my selector made no sense.

I am loving Autocomplete and also Chosen Select (http://modules.processwire.com/modules/inputfield-chosen-select/) which uses http://harvesthq.github.io/chosen/ and is basically the same as Select2 Which one I use depends on the scenario. If you are using Autocomplete, take a look at integrating FieldtypeConcat for the Label field if you want fine control over what will appear in the entries - very cool!

Not saying that it's the only way to go, but I've also built a few sites where authenticated users never get to see the Admin backend, yet so far I've never considered rolling my own system for managing those users. You can simply redirect users away from Admin based on, say, roles -- or whatever other criteria you might have -- so that they never actually reach it. Works fine, and means that you can let ProcessWire handle all the troublesome authentication / permission checking parts

this is a common situation; you have a page field, and you create a new page by adding the options there on the ASM select, but you need some other things to be configured on that page, in your case the category). concerning your first request - the title, that should be set by the option you have entered, as long as you have configured it that way; but if you need more options those can be adjusted on page save using a module; here is an example which you would need to put into a module; for example, i always have a generic 'SiteUtilities' module where i can throw in all kinds of generic stuff without having to make multiple modules, and worry about installing them or keeping track of them; <?php class SiteUtilities extends WireData implements Module { /** * Basic information about module */ public static function getModuleInfo() { return array( 'title' => 'Site Utilities', 'summary' => 'Various utility functions', 'href' => '', 'version' => 1, 'autoload' => true, 'singular' => true ); } public function init() { $this->pages->addHookAfter('save', $this, 'AssignSubCategory'); } public function AssignSubCategory($event) { $page = $event->arguments[0]; if($page->template != 'someTemplate') return; // the template where you want this to run $category = $page->category; // this would be your category field $subCategory = $pages->get("something"); // this would be the page that is the sub-category foreach($category as $c) { if($c->template != 'category') continue; $c->setOutputFormatting(false); $c->sub_category->add($subCategory); $c->save(); $this->message("Sub-category {$subCategory->title} added to Category{$c->title} "); } } } // end class

Just found an article about templating and it really made me smile: Your templating engine sucks and everything you have ever written is spaghetti code (yes, you) I guess many people here on PW don't give much attention to templating engines as PW runns smooth even whithout one. But the concept of DOM Templating really looked interesting to me. I really would like to hear your opinions!

You're right and I'm really with you, that this is really a replacement of logic. The author of the linked article is right on that part. It's just that using the dom does have it's own issues, if you look at the whole process and not only the designers'. E.g. your designer does implement a popular posts list. <ul class="list--popular"> <li> <a href="...">My popular post</a> </ul> Then the backend guy implements this with some dom selectors. .list--popular li > a: Change text to title .list--popular li > a: Change href to url .list--popular li: Loop for all posts Now the designer decides that he would like to have a separate link and the title as heading before that. <ul class="list--popular"> <li> <h2>My popular post</h2> <a href="...">Read more</a> </ul> This would make the whole dom selection in the backend code obsolete. The link's text would be overwritten and the headline wouldn't get the title it needs. The only way around this by just using the dom would be classes like I proposed above. Whereas with something like mustache (just ignore the logic parts for a second, just the variable insertion) the designer could have made this change independently from the backend, just move the curly braces with the variable names around. Additionally you could still use all your dom functions to implement things like loops before rendering out the variables. mustache is simply html with some curly braces the dom doesn't care about. Using the dom could very well be useful in places, but not for basic templating, meaning getting dynamic content in the place the designer wants it to have. Edit: This is really kinda the same discussion as for css specifity. Binding stuff in a scaleable way to the dom is difficult. No matter if it's templating logic or styling. Maybe have a look at this: http://csswizardry.com/2014/10/the-specificity-graph/ and the talk, which includes this as well https://www.youtube.com/watch?v=1OKZOV-iLj4.

What about: http://modules.processwire.com/modules/inputfield-page-autocomplete/

Thank you cstenvsjr, that was the output I want to see. Now that I saw that it was no hanna problem, I found the solution. There was a little include(..) before the posted lines that was responsible for the error. you made my day /thomas

I think your 'another thought' is a better approach since it allows for more granularity, i.e. it targets individual menu items rather than the first approach which targets the whole menu in terms of including natural child pages. I don't think there is a need for the second option 'yes/no' though unless am not getting it? By using the 'include natural children' option, you imply that you want them to be displayed. The way I think I'll do it: 'include_children' => 0//default = no 'include_children' => 1//yes, but only in menu, i.e. render() 'include_children' => 2//yes, but only in breadcrumbs, i.e. renderBreadcrumbs() 'include_children' => 3//yes, in both //number of child nesting levels to show IF include_children > 0 //include_children_levels => 1//default, i.e. show only immediate children [or child in case of breadcrumbs] //include_children_levels => 2//etc....show up to grandchildren/grandchild, etc.. The include_children can be tricky though....One might end-up with lots of sub-menus! But this is is optional, so up to the developer really. Apart from some coding issues I may not have thought of yet, the visual MB aspect has to be considered. Those natural child pages will not be included in the saved menu items, hence will not be displayed in the menu tree in the back-end (ProcessMenuBuilder). They will only be included in the front-end output during runtime. That may confuse your editors, but nothing you can't educate them about, and this is optional anyway. Edit: Or...in the spirit of flexibility and granularity....in MB admin, also add an include_children_levels text (int) box next to an include_children checkbox. Then in the front-end, render() and renderBreadcrumbs() will be guided by: if the setting include_children_levels is empty AND you have an $options = array ('include_children' => xx, 'include_children_levels' => zz), the level set in $options takes precedence and is applied overall except for menu items where the setting include_children_levels is NOT empty; an explicit level set at menu item level will override any $options setting. Would such a workflow work for you?

Another thought I have of doing this is the following though I am not sure if there are any complications making this. What if each separate page added to the menu had an option added to it in the menu builder(where title, url, css options are etc..) such as 'include this pages natural children from page tree' with a second option with it with a yes/no to display children in normal render method? The breadcrumbs could then normally display all levels as the pages would be included in the built menu with the option of not displaying with the normal render method if not wanted there. This could actually be useful in other ways as well if normally wanting to include natural children under a page without actually having to manually put them all there especially if there are many. If this is set up in such a way whereby all natural children are included such as the way a selector works then I assume when adding another page as a child in the normal page tree that it would then be included as well automatically in the menu builder if set up such a way. This could be quite useful making the menu builder much more flexible.

@dazzyweb, OK, I might have found a way to achieve both of these. Although I think it is possible to include intermediate natural parents (i.e. PW parentage) that are also not in the breadcrumbs, I think I will stick to immediate parent only. Same goes for the 'current' class. What I mean is this....let's say your 'jaguar's had child pages as well, maybe 'model A', 'model B', etc., that are also NOT part of the MB menu, following your request, you would something like this: Home / cars / Jaguar / Model A. The problem I foresee is what if an intermediate parent was part of the MB menu but not in a 'natural' position? I we were to include it in the breadcrumbs, it could end up in the wrong position (from the breadcrumbs point of view). I hope this makes sense and maybe this is an edge case. Anyway, unless convinced otherwise, I am limiting this to the immediate parent, e.g. Home / cars / Jaguar /. Thoughts? Edit: No, scratch that. I'll make the depth to which one wants to display non MB items that are natural children of the current MB item configurable, e.g. append_child => 0//default - no child appended = Home / Cars append_child => 1// append the immediate child = Home / Cars / Jaguar append_child => 2// append immediate child and grandchild etc... Beyond that...how you structure your menus is up to you

quick look InputfieldPageListSelect and Autocomplete are subclasses of Inputfield and not InputfieldSelect. Maybe its good to restrict the selectable Inputfields to all subclasses of InputfieldSelect, which includes the method addOption() too. Furthermore render() method should be hookable. Everything else is more on the side of Inputfield Developers. Thanks again

Awesome update! I just played around with automatically detecting all available and compatible Inputfield types: https://github.com/adrianbj/FieldtypeSelectExtOption It works great with all the standard ones as well as other 3rd party ones like InputfieldChosenSelect I was hoping it might also with with Autocomplete and SelectMultipleTransfer but autocomplete doesn't have an AddOption method and InputfieldSelectMultipleTransfer doesn't style properly, but I haven't looked into fully to find out the issue. I have restricted the Inputfieldtype options to exclude those which are a subclass of InputfieldPageListSelection (becaue these don't work at all), those that don't have an addOption method, and then specifically InputfieldSelectMultipleTransfer, although I'd like to figure out a better way of detecting the reason this one doesn't work so it could also match others than won't work. If you want to take a look at my changes, please feel free to incorporate, or if you want, I can send you a PR. Perhaps it would be worthwhile adding a note under the Inputfield selector saying that there are no guarantees that all the Inputfields will work as expected and the user should test carefully.

Can you please let us know what these errors are and what versions were you running on your local install? Did you have any of these problems on your local install? Can you provide a little more information on this? What did you do to get around this? From a strictly technical point, It would be better if you could upgrade your hosted PHP version from 5.3.29 (to PHP 5.4.x, 5.5.x or 5.6x) and possibly have your Apache at the 2.4 branch. I'm also guessing that you already understand that you will never get optimal performance on a Shared Hosting platform. Don't get me wrong, It doesn't mean that things can't work with this configuration. You just need to be aware that there are going to be limitations. Can you let us know what are your load times at different times of day? Are you having this loading problem on different web browsers or OS platforms? Is this the only web hosting company that you deal with? Are you able to load an online dev version of the site on another web host?

Everybody who has import scripts running as a cronjob, there's this effect that the cronjob is run als guest user. So imported pages via API are created and modified by "guest". This is not nice and can lead to confusion. "What?! How can a guest create this page?" To avoid this and set the current user via API you can do this at the beginning after bootstrapping PW: include_once("./index.php"); /** * Overwrite static user for imports. All created pages will now * have created and modified user set to "importer" PW user. * Otherwise API created pages will have the created user "guest" * ------------------------------------------------------------------------------------- */ $importerUser = wire("users")->get("importer"); if($importerUser->id) wire()->setFuel("user", $importerUser, $lock = true); Only thing is you have to create a new superuser with the name you wish to use for such scripts and replace the name in the script. Now if you run this script no matter from where or with what current user you'll have "importer" as the created and modified user. ----- Note: There's a new way to set system vars like $user via wire(name, value), but this doesn't seem to work in this case in my tests. Cause the user will get overwritten again when creating a page by the current user calling the script. I'm not sure it's a bug or what, so it might be possible in future to use the shorter version of wire()->setFuel(name, value).

There's another method to be able to overwrite created user directly when creating a page. There's a new template setting to allow overwriting the $page->createdUser that you can enable to allow this via API. Then you can do this: $p = new Page(); $p->template = "basic-page"; $p->set("createdUser", wire("users")->get("importer")); $p->title = "Imported page"; $p->save();

In backend it works cause there's no outputformatting. Doing in a template you see the error cause front end template context has output formatting enabled. Not sure if pagetable causes issues with clone but can't remember if Ryan said something. So the solution is right there explained in the error if you read it! Try a $pages->setOutputFormatting(false) before your code.

There's also ScrollReveal, which I quite like.

Thanks for your feedback Jürgen! I've tested myself and didn't find any bugs, so i merged into master. Meaning that v. 1.1.2 is now official As described two posts above, this version adds support for multilanguage PDF files. Please make sure that your PDF files are still generated correctly before you update on a live site! Cheers

The user functions in ProcessWire are probably the least developed part so far, but I think it can still accomplish what you want pretty well. Since ProcessWire assigns permissions to roles rather than users, I think the best bet is instead to create one role for clients, and then we'll check if they have access on the actual page by comparing the page name to the user name. 1. To start, create a new role in Access > Roles, call it "client" (or whatever), and give it just "ProcessPageView" permission. 2. Next create a new page that will be the parent of the protected client pages, i.e. "/clients/". Once the page is created, click on the "settings" tab of that page, uncheck the "guest" role, and check the "client" role. Save. 3. Now create a new template and associated page that will serve as the login form. I'd call the template "login" and the page "/login/". The logic for the login template should be something like the following: /site/templates/login.php <?php if($input->post->login_submit) { // process submitted login form $name = $sanitizer->username($input->post->login_name); $pass = $input->post->login_pass; if($session->login($name, $pass)) $session->redirect("./"); else echo "<h2>Login failed, please try again.</h2>"; } if($user->isSuperuser()) { // display links to all the client pages echo $page->children()->render(); } else if($user->isLoggedin()) { // redirect to client page, if it exists $private = $pages->get("/clients/{$user->name}/"); if($private->id) $session->redirect($private->url); else echo "<p>Your page is not yet setup.</p>"; } else { // display the login form include("./login_form.inc"); } I split the login form into a separate file, though you could mix it into the login.php file above too. Below is the markup for the login form: /site/templates/login_form.inc <form action='/login/' method='post'> <p><label>Username <input type='text' name='login_name' /> </label></p> <p><label>Password <input type='password' name='login_pass' /> </label></p> <p><input type='submit' name='login_submit' value='Login' /></p> </form> 4. Now create the client template, that will serve as an individual user's private page. I would call it "client", and insert logic like the following: /site/templates/client.php <?php if($user->name != $page->name && !$user->isSuperuser()) throw new PageNotFoundException("No access"); // if we made it here, you are good to display their photos 5. Now setup your client pages and client users. Create each client page under /clients/, and make it use the client.php template we setup above. The client's username and page URL name must match, so if your client's username is michelle, then her client page should be /clients/michelle/. Also, when you create each client's user account, give each one the "client" role we created in step 1. 6. I think that will do it. Let me know if this makes sense or if you have any questions. Also, I'm doing this all off the top of my head (while also checking the API code), so let me know if you find I'm off on any parts too.