Pete

I think if you change fuel() to \ProcessWire\fuel() on line 250 that might work, or add namespace ProcessWire; to the top of the spex.module file just after the opening PHP tag. If it works, credit goes to Teppo: https://processwire.com/talk/topic/12304-pw-3-devns-cli-not-recognising-pw-classes/?p=114026

What a great way to lose a lot of business - causing hassle for thousands of existing customers! I get that there are always reasons for making hard decisions like this, but the way they've done it (and potentially the timescale if you have dozens of client accounts) sucks! Their new $20 plan also only gets you 25k emails a month and Mailgun gets 50k for the same price. I wonder which I'll be looking at next...

Lowercase and normal case seemed to already be in place for those two (perhaps Ryan fixed this before I got to look at it) but just in case I added all uppercase as an option as well.

It is probably because it's used by a small fraction of businesses. Way under 1%. It's not a big enough name yet for it to appear in many job ads I think. But one day... The job ads that would be applicable for someone who knows ProcessWire would be the ones that either don't list a preferred CMS at all, or if they list a CMS they put "or similar" - I've seen plenty of those. "WP or similar" which is your opening to go to an interview and open their eyes to the endless possibilities and lack of security flaws (in ProcessWire, in case you thought I was talking about the other one ). I think that dev agencies looking for new staff tend to ask here, as that's far more useful. We've seen it happen a few times before, and that's only the ones we hear about on the forums.

Hi all It's been long overdue, but I have approved all pending profiles (well, except one where they were just trying to advertise some database app that had nothing to do with ProcessWire whatsoever!). @rick - it would be nice to do this. I will add it to my list of things to do. Just today I added a manual link in the Dev Directory admin to check the user's "sites using PW" against isit.pw to save me some time so I can certainly see the benefit of automated checks for existing members in the directory too. Can you let me know if that user's website link is still broken please? @incognito.ms - apologies, I was way behind on directory approvals and your profile has now been approved. @Sephiroth - think of it this way, you have the Nigerian market all to yourself then at the moment There are more planned updates to the directory in coming months, and I appreciate everyone taking the time to submit so many sites for verification. I would suggest you all list your sites in the Sites Directory as I can see one or two that aren't there. I appreciate this isn't always possible due to client confidentiality though, but more exposure for your skills where possible can't be a bad thing

I don't share the warm fuzzy feelings I get when I use people's modules nearly often enough, so I just left a comment on the module directory page. The short version is that it's saving me from having to create custom modules for a lot of places where I'd want to output some custom, processed output when editing a page and it is streamlining some of the steps I need to perform when approving entries in the dev directory, so thanks for this!

Erm... But your screenshot shows what I meant? The "rather than" bit I mentioned is translating the module instructions not the output message. Either way, it's all good, and would actually be something that could be added to other modules as well - nice work.

It won't change in any way that will affect you. Since everything is abstracted via the API one of the best things about ProcessWire is that Ryan could rename all the database tables to nonsensical names but as long as it's tied back to the API correctly all the same API calls will still work fine.

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.