Pete

When you have an update between ProcessWire versions, be it 2.x or 3.x there are not usually changes like database changes that affect normal pages. What I will say after running into an error that had no message whatsoever last night with PW3.x is that if you're worried about it, don't use it yet. In my case I switched the /wire folder and index.PHP file back to 2.7.x and carried on with other ways of doing what I was trying to do. I simply didn't have the time on the project I'm working on to troubleshoot. As a general rule, if you're relying on things working perfectly and have limited time then only use final versions of any software. If you have a bit of time to work some issues out and want to use the latest then feel free to use 2.7 dev or 3.x dev (though 2.7 dev is going to be more reliable at the moment because less has changed overall in the core code than 3.x). EDIT: I will try and work out that blank error bug I had last night, but once client work is finished. I enjoy resolving issues, just can't spare the time sometimes when deadlines are looming.

It is literally just for having a draft of an existing page's content in the admin - not a whole new layout/structure etc. If you are looking to build a new version of your site, best to copy your existing site locally or to a dev folder and work on it there before replacing the live site.

I think your language question is around sites displayed in multiple languages (multi language fields etc) rather than translating the module itself into other languages? If so then that is a little tricky I guess - you'd need to iterate the languages and store a message for each language - this code may help: https://processwire.com/talk/topic/4383-how-to-set-language-active-via-api/?p=42956 Please feel free to submit it to the modules directory as it is though - it'll give it better visibility and possibly more feedback

This might help: https://gist.github.com/kongondo/5728053

Thanks for the reminder - I'm pretty rubbish at doing this myself.

Hi Nico If you use ProCache with your module and have your module handling Google Analytics insertion, the GA code is stripped out by ProCache when you tell ProCache to minify the HTML output. Any idea why this happens? I tweaked ProCache not to minify inline JS and it still seems to strip it out, so it's almost like your module is altering the markup and then ProCache is also altering the original markup and overriding your altered markup I think it's going to be something to do with the order they run in maybe, but not sure. Thought you'd be interested anyway!

^ yup. It does confuse people when we say we're not making a concerted effort to compete with other systems, but I think doing our own thing means we can stand back and consider what the user base really will find useful instead of chasing all the features in system X. If gives you a lot of freedom doing it this way.

Your timing is impeccable - just what I need today!

For those concerned about security, you could do this afterwards on Twitter: I can confirm your vote is still there afterwards.

There is a default markup array in InputfieldWrapper ( https://github.com/ryancramerdesign/ProcessWire/blob/980ce4f0be2054dfbad4a7b334d35bdca42da7da/wire/core/InputfieldWrapper.php ): $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='InputfieldHeader ui-widget-header{class}' for='{for}'>{out}</label>", 'item_label_hidden' => "\n\t\t<label class='InputfieldHeader InputfieldHeaderHidden ui-widget-header{class}'><span>{out}</span></label>", 'item_content' => "\n\t\t<div class='InputfieldContent ui-widget-content{class}'>\n{out}\n\t\t</div>", 'item_error' => "\n<p class='InputfieldError ui-state-error'><i class='fa fa-fw fa-flash'></i><span>{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>", 'item_icon' => "<i class='fa fa-{name}'></i> ", 'item_toggle' => "<i class='toggle-icon fa fa-angle-down' data-to='fa-angle-down fa-angle-right'></i>", // ALSO: // InputfieldAnything => array( any of the properties above to override on a per-Inputifeld basis) ); You can override this with your own array: $form->setMarkup = array( // your stuff here ); And the last note in the first code block there says you can override per field as well, so happy days - you can do InputfieldText and so on and play around and see what happens. I would suggest {attrs} would always be required for simple fields like input type=text etc as this will have the field name and so on.

Reno - it's included in most recent versions. Just noticed the logo you have for the Blog menu item

Love the joke in the module title

You will be assimilated. Resistance is futile. or We only wish to raise quality of life for all species.

I meant I'd like to see Win7 and 8 disappear too personally

Woohoo! They're definitely on a drive to get people updated across the board even if this announcement didn't specify OS. It's got to be expensive to keep supporting old stuff. Now can Apple just end support for Safari next? All versions? Found a load of Safari-only quirks in a site I'm working on at the moment and it's doing nothing for my mood

I read a bit more into MUUT and they just keep their database totally separate, so the users only exist in the CMS you choose. So basically, if you ever switch CMS, you would need to convert your user accounts to a new CMS and change the MUUT user array data to the new CMS' variable. Not a big deal actually. What I meant by the $user conflict is you can't have two things called $user. $user is reserved in ProcessWire, so not sure what the options are there. There also doesn't seem to be anything in the index.php you posted above that actually does anything to do with MUUT, however now I say that I see the JS at the end that points to the URL of the MUUT forum, so maybe it's passing some variables via JS? The reason I asked about index.php is because in ProcessWire you don't do any templating in the root index.php file. You edit the templates in /site/templates/ instead. I think, whichever CMS you ultimately settle on to work with MUUT, you need to understand the CMS you're using and how it works first, so read some tutorials, look into the docs and watch the overview video (quite out of date now, but gives you an idea of how things work). I'm also concerned when you say you have time constraints - what you're attempting to do isn't simple if you're not au fait with both systems, though top marks for diving in at the deep end and giving it a go

So your index.php file - is this in ProcessWire and loading MUUT inside ProcessWire? Then you would have access to PW's current user. There will be a conflict if this is how your code above works as your user array is called $user but in PW $user is an object containing the current user data. As for whether there is an avatar field in ProcessWire - not out of the box, but everything in ProcessWire is custom fields so all you need to do is go to the admin, create an avatar field, assign it to the user template and you're sorted. In summary, yes this looks correct: "id" => $user->id, "displayname" => $user->name, "email" => $user->email, "avatar" => $user->ICouldntFindWhatWouldGoHere but you need to create an avatar field. Also note that this does not magically give you a tie-in between registration/login systems between the systems from what I can tell. For example, in ProcessWire there is no default front-end user registration/login system (there are many topics and at least one module covering this though) so I see nothing above where MUUT would talk to ProcessWire and synchronise user data - it's actually a little odd that I can't find anything relating to this in their docs. If instead it means MUUT just works with whatever ID ProcessWire passes to it then if you ever wanted to change CMS in future you would be in real trouble as the link between the two systems would be tenuous at best.

"I said go daddy, stop lazing about on the sofa"

No worries. It's not specific to PHP as you can't always guarantee a true or false response from the above code, just I know true or false is what is returned for PricessWire's checkbox values when using them in frontend templates. The actual printed value if you echo'd it would be a 1 I think if it was checked, else blank. It's always worth echoing a field to see what the actual value is, so echo $page->footerChecked in this instance.Other fields will return different values - some arrays of pages so let us know if you get stuck with anything else - there's plenty of help around the forums

I believe this is all you need: if ($page->footerChecked) { // true } else { //false }

Hehe, I chuckle when people write "bare with me" which would be a whole different picture

Hi folks There are quite a few approvals awaiting processing - I'm aware of these and will get to them over the course of the next week. There are still a few bugs cropping up in the system that I need to deal with first to prevent anyone having to add their info again and again. Bear with me a little longer.

Looking forward to finally getting the forums upgraded to 4.1 - just need to clear some work out of the way and we can get this done in Q1 easily enough, which is something of a necessity since the current version reaches end of support in June.

Editors like PHPStorm (which I know a few here use) will highlight variables the same however you use quotes, so shouldn't be any harder to spot. I know Ryan uses PHPStorm and so do several others here but not sure if other editors cause variables to be less noticeable?

Shows WordPress is still on the rise.