Leaderboard

Chrome Php Logger Module to log useful details directly in your Chrome JS console. You can inspect most as objects and see infos or values. To enable logging with this module you have to enable debug modue in config.php. If debug is set to false in config.php, it will not output any log. Important: It is not recommended to enable it on live stage, as it reveal infos you might not want everybody to see, although it's not obvious as it requires the ChromePhp Extension installed and enabled. - render time - memory consumption - cpu usage - current user infos - current user roles - current user permissions - current page with all its fields and their value and field settings - page cache/loaded on request count - fuel - modules loaded - Server vars etc. - Cookies - Requests - mySQL query log When installed you can also use ChromePhp static methods to output your own data in all your templates or modules: ChromePhp::log($page->somefield); Note: This module requires the ChromePhp Extension installed to see the log in the Javascript console. More infos can be found on http://chromephp.com Download: Modules Directory: http://modules.processwire.com/modules/chrome-php-logger/ Github: https://github.com/s...ChromePhpLogger

I'm on a mission! Trying to give back after all the millions of questions I've asked myself....

I've just redone a charity website for a charity we're involved with, using the "profile" I'm developing. It will fill out more as they add content. Icons are added when they specify twitter ids, RSS etc. There are also events pages, testimonials, partners, categories but they are by default unpublished. Latest blog posts are populated lower down when they get round to doing some, so it's not in it's finished state! http://www.madhatterscharity.com

I can see that! Personally this makes me feel that the time I took to answer some of your questions was more than worth it edit: and I think the others share the same feeling

Perhaps some kind of gallery for admin themes & predefined profiles?

Edit 2013-01-09: This module is deprecated - see the next gen version here: http://processwire.com/talk/topic/2515-module-aftersaveactions/ - - - After following the discussion on multiple save buttons and default action after page save I decided to give it a try. The result (or an early version of it to beat Soma ) is a module called PageEditRedirects. The module, inspired by this post in particular (and another module by adamkiss), adds four options to choose from when saving a page: stay in editor (default) go to the page list add a new sibling page view the edited page The options are always collapsed and the chosen option is saved into a cookie so that each user's preference will be remembered. Probably should add a checkbox "Remember this setting" (unchecked by default) so that a one-time use of another option doesn't get sticky. Module can be downloaded from https://github.com/n...geEditRedirects and wont be available from the modules directory just yet (because of the required PW 2.3). So, consider the module just an alpha version or a proof of concept as it hasn't been tested nearly at all (need to check it doesn't break Antti's Adminbar for example). Edits: * Added link to an early post on the subject. * Added a little more explanation on what the module does and doesn't do. * Removed the note on needed core changes (Ryan did those already).

Hello everyone, I'm currently working on a simple module (view this thread for more details) and ran into some problems with the validation of input data. I did some research, but I wasn't able to find answers to these questions: 1. If you develop your own Inputfield/Fieldtype module, where do you do validation? I've seen other modules do it in Fieldtype::sanitizeValue() (apigen), but this seems rather strange to me. Also, as far as I got it, they didn't throw any errors back to the user but just quietly changed everything, that doesn't make sense without the user knowing it. This leads to the next questions: 2. What is the correct way to get visual validation error reports to the user? 3. How to prevent a page from saving with validation errors? With this fairly basic stuff (where I wasn't really able to find something meaningful about) out of the way, what I really want to know is this: 4. How do you add validation with error reporting to an existing Fieldtype module? I want to add my custom validation with error reporting to the standard FieldtypeTextarea module (only when some conditions are meet in the corresponding Inputfield for sure), but I have no clue what would be the way to go there and wasn't able to find any module that does it like this. Please shed some light on these question, would be very much appreciated! Marc

Hi Diogo, thanks for the feedback. The icons look a lot better when there's more of them, they're triggered when their details are entered on the settings page, I've added it in temporarily to see the effect. I've also redone how it works on smaller screens, though I find it hard to fit everything in and not take up to much vertical space... Would you keep the homepage slider the same height, I'm thinking it may be taking up too much room and may be better less height like on the other pages, I'm not sure? For the pictures, you're right they look a little small on smaller screens though I don't really think I can change that as they are set to crop but bootstrap is fluid on smaller screens, so I think that's why they're getting reduced? Cheers Joshua!

Hey boundaryfunctions, As soon as I get it working properly I will definitely add it! I'm trying to do two things: 1. Cut the entry off after the maximum characters 2. Make the "characters left" turn red when the user gets to < 10 characters remaining The first one is really required. The second one is just a nicde touch, but again this is all about getting faster with ProcessWire as well as making a functional module. Thanks, Matthew

Hi boundaryfunctions, We are totally in alignment. We need... 1. The immediate-response thing for stopping innocent people from wriitng a novel only to find out afterwards that we only want 100 characters 2. The server-side validation to make sure the 100 characters are not evil Just for the moment, I'm trying to integrate number 1 into the plugin under discussion. I also leave open the possibility that PW has validation elements already available, and I just am not yet using them. Thanks, Matthew

Hey Matthew, I'm totally with you about the immediate-response-thing, that's absolutely something that has to be there. You already posted some links to jQuery plugins that do this yourself, they all work basically the same way: on every interaction with the input, check whether the limit was reached and if it was, cut away all characters beyond the limit. Since the rise of HTML5, there's the maxlength attribute, too. While this is all nice and therefore should and will be used, client-side validation can never substitute server-side validation. I know, that in the normal use scenario, you only have accredited users on the system that don't want to do anything nasty with it, but still: you may always have a Javascript error somewhere else that prevents your validation code from execution, Javascript may be switched off, the maxlength attribute isn't supported in older browsers, everything that can possibly go wrong will go wrong, everything that can't go wrong will almost certainly go wrong, and it would be nice if this would module could be used safely in all kinds of frontend forms, too (because it probably will the sooner or the later). All of these are imho good reason to do server side validation, even if you don't expect the evil user.

Am I missing something here? I've never had a problem with this working img { max-width: 100%; height: auto; } I've never needed to remove either the height or width attributes, or are you trying to accomplish something different than what I am thinking?

onchange part if you have jQuery: If you have jQuery loaded, this example look nicer I think. ( although your inline js is quicker ) // check if input select exists & stick the onchange part to it if($("#mobile_menu").size() > 0) { $("#mobile_menu").change(function() { window.location = $(this).find("option:selected").val(); }); }

Just pushed an update to support config true, and added check for getrusage support. To enable logging with this module you have to enable debug modues in config.php. If debug is set to false in config.php, it will not output any log. Important: It is not recommended to enable it on live stage, as it reveal infos you might not want everybody to see, although it's not obvious as requires the ChromePhp Extension installed and enabled.

Well, that is the default behavior: sanitize and let it be. It was just recently when we got the "required" which is only thing that throws inline error on top of the field. Maybe search the source how it does it? (I don't know myself, haven't taken a look yet) The few times I have done something similar I have hooked into page save and throwing just general error message: $this->error("You have too many characters in your body-field, some cropping occured"); This might be for a little help: https://github.com/formmailer/SchedulePages/blob/master/SchedulePages.module#L102

Put it in the Wiki? In the longer term I think there will be a proper documentation system based on PW. But for the moment, the Wiki is an excellent collecting and collating system to start getting what is needed down on paper ,,, er, as it were. Ryan is away for a few days I believe, but any that do not have a wiki account can ask him when he gets back. Joss

Hi Matthew, thanks for testing and doing research! I'll definitely add some means of limiting the input clientside, but I also want to validate this clientside. I know, that the inputfields should have to deal with thrusted content only, but still, I think it is a question of good coding style to validate everything serverside as well, just to be really sure. I looked into other modules to see how they do it, and it looked to me, that all of them do their "validation" in Fieldtype::sanitizeValue() (apigen) and without throwing any errors. Is this really the proposed way to do this? This seems really strange to me, why is there no Fieldtype::validate()? Even if this is the way to go: Fieldtype:sanitizeValue() isn't hookable, so how could I slip my own code into FieldtypeTextarea then? Can someone please shed some light on this? Edit: Since I think answers to these questions might prove helpful to others as well, I opened a new thread in the Module Development Forum, asking the question a little more generalized. You can find it here: http://processwire.com/talk/topic/2365-validation-for-own-inputfieldfieldtype-modules/

Good job Soma! I like the way you're thinking - I had a module with just slightly less functionality coming up, this week even . But now I don't need to find time to finish it as you've already done things bigger and better. One thing I'd like to see is a little if-statement to disable this when $this->config->debug is false. That would prevent internal structures being displayed at production stage if (when!) debug-mode has been properly disabled.

Hey Matthew, you're welcome. Thanks for the feedback and you're right, most oft the credit goes to Soma. This isn't in the Moduls repo for now because I wanted to get some things right in the first place, but I hope it's going there soon. I did some searching but didn't really solve this problem, so I hope someone can give me a pointer on this: where would I hook to do some custom validation for my input field (including error reporting)? Any help is very much appreciated.

// output the 5 authors with the most posts sorted by post count $authors = $pages->find("template=author,posts.count>0")->sort("-posts.count")->find("limit=5"); foreach($authors as $a){ echo "<p>$a->url $a->title ({$a->selec_page_image->count()})</p>"; } This seems to work, but only if you make the sort and limit after the find. I'm not sure what exactly happens, but if you put sort inside first find it will throw error, now it works if added afterwards. The last find is to limit it to 5. Note limiting has to be after the sort, otherwise you get a mixed result obviously.

I agree with pretty much all of what he says and wonder if we should be checking for any topics with zero replies? I could run a query sometime next week I suppose (busy this week).

Another one from gadgetopia, and this time is about all of us http://gadgetopia.com/post/8286

I'd like to hear Ryan on FLOSS weekly (not a dental product.) That would be some great exposure for PW, especially now it's just won the best free cms award too.

Not sure what you're about. But this should give a select menu dropdown $treeMenu = $modules->get("MarkupSimpleNavigation"); echo $treeMenu->render( array( 'collapsed' => true, 'max_levels' => 1, 'outer_tpl' => "<select>||</select>", 'list_tpl' => "||", 'item_tpl' => "<option value='{url}'>{title}</option>" ) );

maybe: $options = array( 'has_children_class' => '', 'levels' => false, 'max_levels' => 2, 'show_root' => true, 'outer_tpl' => '<select id="select_mobile">||</select>', 'inner_tpl' => '<optgroup label="¬">||</optgroup>', 'list_tpl' => '||', 'item_tpl' => '<option value="{url}">{title}</option>', 'item_current_tpl' => '<option value="{url}" selected="selected">{title}</option>' );

Great tutorial Soma! This is the best summary of using PW's Inputfields that I've seen. I noticed you did $field->attr('id+name', 'email') so just wanted to explain what that is for those that may be unsure of the syntax. That syntax is basically saying to set the 'id' and 'name' attribute to have the 'email'. While every field needs a 'name' attribute (like in HTML) the 'id' attribute is optional… if you don't assign an id attribute, PW will make one up. If you intend to custom style a field with CSS or target it from javascript, then it's best to assign your own 'id' attribute. Otherwise, it doesn't matter. // this… $field->attr('id+name', 'email'); // …is the same as: $field->attr('id', 'email'); $field->attr('name', 'email'); // …as is this (direct reference): $field->id = 'email'; $field->name = 'email'; The advantage of using the attr() function over direct reference is that attr() can't ever collide with other Inputfield properties that might have the same name as a field attribute. It's basically your way of saying "this should definitely be an HTML attribute and not anything else." For recognized attributes like 'name' or 'value' it doesn't matter what syntax you use because an Inputfield already knows 'name' and 'value' are standard HTML attributes. But if you needed to add a custom attribute like "data-something", well then you'd definitely want to use the attr() method of setting. That attr() method should only be used for things that would actually be HTML attributes of the <input>, because they will literally end up there. So if you do an $field->attr('label', 'Hello'); you'll end up with an <input label='Hello'> in the markup, which is obviously not something that you want. That's why you assign a non-attribute property like 'label' or 'description' directly, like: $field->label = 'Something'; Last note about $attr() is that it can be used for both setting and getting attributes: $field->attr('value', 'something'); echo "The field's value is: " . $field->attr('value'); // same as: $field->value = 'something'; echo "The field's value is $field->value"; To extend your example, lets say that you wanted the 'email' and 'password' fields in a fieldset titled "About You". You would create the fieldset, and then add/append the fields to the $fieldset rather than the $form. Then you'd add the $fieldset to the $form: $fieldset = $modules->get('InputfieldFieldset'); $fieldset->label = 'About You'; $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $fieldset->append($field); // append the field $field = $modules->get("InputfieldPassword"); $field->label = "Password"; $field->attr("id+name","pass"); $field->required = 1; $fieldset->append($field); $form->append($fieldset); Or lets say that you wanted those 'email' and 'password' fields to be each in their own column so that are next to each other horizontally rather than vertically. You would assign the 'columnWidth' property to both the email and password fields. In this case, we'd give them both a value of 50 to say that we want them to be a 50% width column: $field->columnWidth = 50; To jump out of tutorial mode and into idea mode: lately I've been thinking that PW should have a YAML to Inputfields conversion tool in the core (something that would be pretty easy to build), so that one could define a form like this: And create it like this (where $yaml is the string above above): $form = $modules->get('InputfieldForm'); $form->load($yaml); echo $form->render();

Nico, this has been added in the latest commit of 2.2. To make use of it, have your hooked function (getPage in your case) do this: $event->replace = true; // now original function won't be called $event->return = 'you are now providing the return value'; Also your hook obviously must be a 'before' hook in order to replace the original. So you'd init the hook like this: $this->addHookBefore('ProcessPageView::execute', $this, 'getPage'); Unrelated to the above, but another cool addition: I upgraded the hook system so that it will let you set or get hooked function arguments by name rather than just by position. So if you'd hooked into Pages::save, and you wanted to refer to the 'page' argument, you can now do this: $page = $event->arguments('page'); Before you could only do this, having to know what position the argument was in: $page = $event->arguments[0]; You can also set arguments back to the event by name if you want to, i.e. $event->arguments('page', $mypage);

I just edited the TinyMCE settings and removed width and height from valid elements (input tab). I left img like this: img[src|id|class|alt] EDIT: There is much better solution than this. Just leave width and height intact and use max-width: 100%, height: auto on your css. More info here: