Leaderboard

Hi guys! So, we launched two more websites and more will follow soon. http://mlausen.com/ Multi language and responsive site for a German architect/photographer based in Switzerland. This site is for showcasing her (exclusively b/w) photography and writings. Maike is very happy with PW, and said that she had fun while updating the content. -- http://demenzinitiative-karlsruhe.de/ Very simple and simple to use (by concept) website for a dementia support initiative in Germany. This website has three different layouts depending on the screen size, so make sure you resize the window, and zoom out if you don't have a large screen. The illustrations are by us -- Both corporate identities were also created by us.

New version 0.1.0 adds some more spam protection possibilities and logging. CSRF validation mark messages as spam (by mail or/and ip address) logging for received messages and spam sort option for repeater items in backend to get the latest to the beginning of the list For more information have a look at the readme. NOTICE: If you upgrade an existing installation from 0.0.9 and below to the current version, there are some steps to be taken.

Set $config->advanced = true and whole new (and dangerous) world opens.

updated my post....good call, links and context are very helpful. Thanks for the feedback.

I took most parts of your code and implemented it. It works. InputfieldSelectMultipleTransfer expects item-content class 'InputfieldSelectMultipleTransfer', which is not rendered. tested with InputfieldWrapper. It would be great if the developer could change this and make the module flexible like InputfieldChosenSelect. I like also install method in this one, which adds the module to InputfieldPage settings otherwise it should be done by hand. Thanks a lot for your support.

Depending on your ProcessWire version, you have to enable the access on template (system template: user) level as well.

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.

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 can also do: $field->addClass('myclass');

Ah sorry, I read that too quick (on mobile). Now at the laptop, I see that you're getting the config value from the field. I did that here too https://gist.github.com/somatonic/4252958 Since the property isn't set in construct, it's not automatically set to the field from the config data.

For improving the image processing you'll need to contribute to the gd library not processwire. Alternativly you could use imagemagick, which is more powerful than gd.

Understood, although I am not totally sure on the difference between what @thetuningspoon (the developer previously known as @everfreecreative) was doing and what I needed. I needed the following: $f->attr('checked', $this->fields->get($event->object->name)->allow_overwrite ? 'checked' : '' ); here: https://github.com/adrianbj/TableCsvImportExport/blob/master/TableCsvImportExport.module#L55 If I switch to simply $event->object->allow_overwrite, it doesn't work. What I have makes sense to me because it is the getting the allow_overwrite value for the field name that I am getting with $event->object->name, although I would have thought it would also work with just $event->object->allow_overwrite. What am I missing?

It should redirect to fi.processwire.com, need to check this with Ryan (current error comes from his server) .

Adrian, I just played around with this some more and discovered that the api call was unnecessary. The only thing I was missing was the "object" property. So $event->object->editable returns what I'm looking for. Here is my modified hook: public function hookAfterGetConfigInputFields(HookEvent $event) { if($event->object->hasFieldtype !== false) { $field = $this->modules->get('InputfieldCheckbox'); $field->attr('name', 'editable'); $field->attr('value', 1); $field->label = $this->_('Use page edit link?'); $field->description = $this->_('If checked, pages selected with this field may be edited in a modal window.'); if($event->object->editable) $field->attr('checked', 'checked'); $event->return->append($field); } }

Have you checked the value of $event->editable ? I am not sure in your situation, but you might try this. Of course my ternary approach is not relevant, but you might need to get the value of editable like this: $field->attr('checked', $this->fields->get($event->object->name)->editable ? 'checked' : '' );

Are you using a jpeg image? Pngs (and maybe gifs, too) can't have it's quality changed.

I saw Adrian's GitHub issue report and just pushed a fix to dev (core) for this. It was attempting to count the number of populated rows, and of course there can't be any. Now it checks to see if the Fieldtype lacks a table definition (schema) before attempting to count rows. I suppose this only affects FieldtypeConcat, but it's possible other Fieldtypes in the future may not need their own table for one reason or another.

should be really simple; this is untested, but this is basically the idea: <?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, 'AssignCatToSubcat'); } public function AssignCatToSubcat($event) { $page = $event->arguments[0]; if($page->template != 'thing') return; $category = $page->cat; $subCategory = $page->subcat; $subCategory->setOutputFormatting(false); $subCategory->cat = $category; $subCategory->save(); } }

At least you have to give them the permission "user-admin". And maybe other permissions like page-edit is needed too, but this I don't know for sure. But you can try it out.

You may need to look at and possibly increase the max_allowed_packet variable in MySQL.

Allowed memory size of 33554432 bytes exhausted This is generally the error for to big images. Error: Exception: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away This seems to be more likely a serious issue. Maybe check back with the hosting company why this happens. Look at the console of the browser development tools when you're on a page which is affected by your issue. It will show you all the errors happening there.

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.

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

Hi, Can you also check the error log in /site/assets/ and report any errors here? Also check if you get any javascript errors in the backend Cheers

@Neeks: Please add the link to this post, so that others can read it in full and also can get aware of the original context, authors etc.! https://processwire.com/talk/topic/9376-mysterious-white-line-wiretabs/

As I did a lot of performance optimization stuff for a client's website recently I thought I'll share some of my findings: - optimizing for "time to first byte": Apart from fixing performance issues with your php code there is an easy way to "get things started":Chunk your Output! Doing an ob_flush (or {% flush %} if you're using twig) here and there is an easy way to split your page into chunks that are instantly (and in parallel) served to the client instead of rendering the whole page at once. This is especially handy if you're using the next technique: - Inlining "above the fold" content I must admit that I'm not a big fan of inlining things. In my opinion it's against anything I've learned about keeping things "dry, clean and separated". That's why i refused to do it until now. But if you're using grunt/gulp (and especially criticalcss) you're not doubling anything and the inlining is just another task in your gruntfile. There is a pretty easy step by step guide by Jeremy Keith at https://adactio.com where he explains why inlining css on the first visit will gain your site a massive (perceived) performance boost on the first load (this is especially handy on mobile devices). I'll post a recipe to processwire-recipes.com how to achieve this with processwire in the next days - Avoid loading Webfonts directly but do it asynchronous as "Progressive Enhancement" (+ Store them in localstorage to load them super fast afterwards) to avoid blank pages: http://bdadam.com/blog/loading-webfonts-with-high-performance.html Just implementing these 3 (pretty easy) things made the pagespeed score climb up by 15 points and lowered the perceived loading time by at least 2 seconds below the "critical hurdle" of 1-2 seconds.

I have seen that error when fieldtype doesn't match input or a required field is empty, but it generally informs me what field was the problem (with a big old red notice on top of the field too). So that's weird that you're not getting any description of the problem. If you haven't added any of your own fields to the user template and have checked/double-checked the input of every form, here is what I would do : 1. turn on debug in /site/config.php and see if it gives any extra information 2. If that fails, search the code to see where it outputs that error. (Only one place: https://github.com/ryancramerdesign/ProcessWire/blob/676458407bd530b69b50c6ef2f44cf16e4ef4449/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module#L211) Based on that it's safe to assume you have some formErrors. Look a few lines before that (L195), I would temporarily change $formErrors = 0; foreach($this->notices as $notice) { if($notice instanceof NoticeError) $formErrors++; }to $formErrors = 0; foreach($this->notices as $notice) { if($notice instanceof NoticeError) { $this->error('Notice: '.$notice); $formErrors++; } } That might give you a clue about the notice that is causing a formError. Once you get that info (or even if you don't), you should undo the changes you made to the module file. Anyway it's a hack, but it's how I sometimes investigate what is happening...

I solved my own issue, I ended up using one image field and using the limit=1 method. Works like a charm!

Don't call it pages, call it content type. While ProcessWire is using the name or label "Pages", it can be basically everything. A user is a page, the whole admin area consist just of pages and you could create your own content types. What you mentioned is basically there. Use templates for your content types, link them with the Page (PageSelect) field and then you can cross-access values in the tempalte files. Quick Example: Create a template for product, add the needed fields. Create "Products" by creating new pages with that template. Now create a field with of the "Page" type and call it product. This allows you to link pages. Set it to "Single item" and add it to your desired "Page"-Template. Now you can select your product on the other "Page" and access it via API with $page->product->title

Bingo My assumption from my previous post was right. The PWimage plugin needs a hidden text input field with the value set to the page id of the page that you want to grab images from. I added a hidden input field to my form with $imgPageID = $pages->get("template=media, created_users_id=$uID")->id; $field = $modules->get("InputfieldText"); $field->label = " "; $field->attr("id+name","Inputfield_id"); $field->attr("value",$imgPageID); $field->attr("type","hidden"); $adform->append($field); Now I can choose images from the user's images page And there is no custom module with hook to ProcessPageEditImageSelect required. EDIT: This only works for PW 2.5. For 2.6.x some adjustments are needed. You'll find more info here

I would try to work as much with what PW gives you and adapt the CSS, I think there's even an responsive theme in Formbuilder... but could be wrong. If you really need to adapt the HTML markup and CSS classes used by the InputfieldWrapper you can. As in this thread already mentioned: from the InputfieldWrapper.php core class /** * Markup used during the render() method - customize with InputfieldWrapper::setMarkup($array) * */ static protected $defaultMarkup = array( 'list' => "\n<ul {attrs}>\n{out}\n</ul>\n", 'item' => "\n\t<li {attrs}>\n{out}\n\t</li>", 'item_label' => "\n\t\t<label class='ui-widget-header' for='{for}'>{out}</label>", 'item_content' => "\n\t\t<div class='ui-widget-content'>\n{out}\n\t\t</div>", 'item_error' => "\n<p><span class='ui-state-error'>{out}</span></p>", 'item_description' => "\n<p class='description'>{out}</p>", 'item_head' => "\n<h2>{out}</h2>", 'item_notes' => "\n<p class='notes'>{out}</p>", ); Using the form inputfield object you could simply $form->setMarkup(array('list' => "<div {attrs}>{out}</div>")); The same exists for the classes used. But at the end I don't know if messing with it helps. Rendering form fields: As I said earlier, it's always possible to render a certain field explicit. echo $form->get("name")->render(); You could even use the form building method in this thread starting post and render fields where you like. There'll be still markup being outputed depending on the inputfieldtype, but maybe allows for more flexibility. $showform = true; $form = $modules->get("InputfieldForm"); $field = $modules->get("InputfieldEmail"); $field->attr("name", "email"); $field->label = "Email"; $form->append($field); if($input->post->submit) $form->processInput($input->post); if($form->getErrors()) { $showform = true; } else { $showform = false; // form valid, do something } if($showform) { echo "<form action='#' method='post'>"; echo "<div class='row'>" . $form->get('email')->render() . "<div>"; ... } Anything is possible, just use what you need. Think it's almost same as you would work with fields or pages.

Process is just an abstract module designed for extending. Its behavior is pretty simple in that it calls a method in the module matching the first URL segment. If there is a URL segment, it calls execute[urlSegment] in your Process module (if it exists), with the first character of the url segment in uppercase. For example, if your URL segment was "new", it would call executeNew(). If there is no URL segment, then it just calls execute(). So it is just a basic mapping of URL segments to methods with execute() being the default. I suppose this is kind of similar to code igniter except for the naming (with execute… being part of it) and PW doesn't pass any arguments to the execute() functions... rather you can retrieve them from $input->urlSegment($n) if you want them. All of those execute[?] methods just return the content (markup) to be output. It is output directly in the #content div of the admin template. Unless the call was initiated by ajax, in which case just your output is sent (without the HTML document). Another differentiating point of Process modules is that if you have a .css or .js file in the same directory as the .module, with the same name as the module, it will be automatically loaded. Lastly, if you edit any admin page, you'll see it lets you select what Process module to execute on that page. This logic can be applied beyond just the admin template if you want it to. It's a bit late here and I may be forgetting some things, so let me know if I'm not making sense or can provide any more info. But just wanted to reiterate that Process modules are very simple and there's not much to it.

OH. MY. GOD. Tell me I'm not dreaming! I've been scouring the Internet for weeks looking for a CMS that would allow me to give my clients a decent user experience. I've developed sites in Joomla, Drupal, Silverstripe, and Wordpress. Joomla was a nightmare of epic proportions. The admin interface is confusing and inconsistent. Drupal had promise in theory, but trying to customize it just caused it to bug out. Silverstripe is nice, but the admin panel is slow and clunky. Wordpress is great for blogs, but feels like you're hacking it if you're trying to use it for more than that. After my frustrations with the big name CMSs, I decided to try and get a better lay of the land and see what else was out there. Every one of them was either lacking a crucial feature, poor on the usability front, or a buggy mess. I have some programming knowledge, but mainly I am a designer looking for a CMS that lets me design the client's experience in the same way that I'm able to design the end user's experience. I don't need templates or templating languages. I want something that lets me be the designer and then gives my clients the power to work with what I've developed. As someone deeply concerned about user experience, I don't understand it. How could so many developers get this so wrong? Were they just throwing these things together without thinking about the use cases? The need for flexibility? What people actually NEED in a CMS? I was beginning to think I'd have to become a PHP developer and build something from scratch. So far, what I see in ProcessWire is almost exactly the ideal CMS I have been piecing together in my mind's eye. The consistency in the mental design model, the absolutely crucial ability to create your own page types and custom fields for your clients which is utterly lacking or nonexistant in nearly every major CMS, the ability for logged in users to easily update a page they're on by simply hitting an "edit" link from the front end... Elegant, logical, and flexible. It's obvious that you've put a lot of thought into this. Thank you. I can't wait to get started.