Pete

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.

It's out of choice I believe. That website's votes can be easily rigged and they hadn't done anything about it last time this was checked (which was a while ago). I think it's still the case as numbers of votes on pages like this seem quite high for some less well known CMS': http://www.opensourcecms.com/scripts/show.php?catid=all&category=All+CMS+Demos Without naming names, there is one script on there with 3/4 the votes of Drupal but whose forum has just a few dozen members. That seems a little fishy to me. Plus Wordpress on page 2 just going by number of votes? Seems unusually low for what is, without question, the most widely-used CMS on the planet.

What Martin said two posts above - for folks looking for some familiarity moving from MODx, the Hanna Code module is definitely your friend as its really powerful and you can use these codes inside any textarea field that you have set to parse Hanna Codes.

This may get you a bit closer with Phantom.js if you know the coords of your CKEditor field: https://github.com/microweber/screen

Here you go: http://stackoverflow.com/questions/13106299/redirect-using-htaccess-based-on-referrer Actually, that link I posted is part of the puzzle, what you might actually want (untested) is this since you know the referring domain: RewriteEngine On RewriteCond %{HTTP_REFERER} ^http://the-naughty-domain.com [NC] RewriteRule ^ http://the-website-of-your-choosing.com/ [L,R] Basically targetting only the naughty domain and sending them somewhere else. This can also be changed to do any of the other actions discussed in this topic.

Not quite what you're looking for, but this may be of interest: https://github.com/niklaka/ProcessWireTests

It was definitely one of those things where when I was having the conversation with Ryan it suddenly clicked that I'd overlooked such a simple option. Still looking for something more complicated when ProcessWire offers so much simplicity and elegance - one day I will learn

Something else to note as per this Github discussion: https://github.com/ryancramerdesign/ProcessWire/issues/1466#issuecomment-150174471 Whilst setting the value of the "title" field to something custom for this purpose shouldn't mean the actual page title gets overwritten, you never know what custom modules are running in the background that might cause your custom title to get saved, however unlikely. If you want to play it really safe, assign the custom value to _title instead of title (so just a fake field name) and then set the option in the field setting to {_title} instead of {title} It's not paranoia if it saves you from a lot of headache further down the line

Just thought I'd add that if you thought it was malicious then diogo's way above might be better: https://processwire.com/talk/topic/11380-exact-illegal-copy-of-my-site-on-another-domain/?p=106247 as it will show a forbidden warning, rather than cause potentially dodgy urls to redirect to your site as per Ryan's solution. Either is valid - just different results for anyone loading the URL in question. If it was a dodgy XXX url for example (I know it isn't in this case) then showing a forbidden warning might be preferable to something that sounds a bit x-rated silently redirecting to your domain name

I've come back to this topic myself about 3 years after having a similar need in a different thread. This code, from Tom's activity log module and altered slightly, gets both an old and new version of the page when hooking before saveReady: $clone = clone($page); $this->pages->uncache($clone); $old = $this->pages->get($clone->id); // Now just echo both the fields you are interested in: echo $old->field_of_interest . " becomes " . $page->field_of_interest; exit; On save, that should give you access to the old and new versions of the page where you want to compare just one or a few fields and you know which ones you're interested in already. Seems to simple now when you see the use of clone()

Haven't looked back yet with FutureHosting. London datacentre is an option with the benefit of US prices, managed service option, SSD-based VPS/dedicated servers, heavily discounted SSL certs (if you need them), WHM and cPanel for us GUI guys

Strange link on that topic: https://codex.wordpress.org/Function_Reference/capital_P_dangit

Just a quick note - the point of doing this was to categorise blog posts both against existing pages (rather than having blog categories with the same or similar names) as well as additional categories that only apply to blog posts. This makes for far easier cross-linking of content (I can have the latest blog post for a type of surgery teased on that surgery page), which is something ProcessWire handles beautifully.

Hi folks So I actually just added this as a pull request on Github before figuring out it's already possible in the system. What I wanted was an ASMSelect field (can be a normal select or other Page field) where the list was ordered in a certain way and pulled from two sets of pages with different templates. The trick was that I wanted the labels for one set of pages to include the parent page name in the label so they're sorted by parent title, then title, but the other set of pages was just to be added to the end in alphabetical order. I've anonymised the example somewhat, but I have a medical blog where I wanted to categorise posts against medical procedures listed on the site, as well as other blog-specific, general categories. To achieve what I wanted, I selected ASMSelect as the Page Inputfield type, then used the "Custom PHP code to find selectable pages" option and did this: $options = new PageArray(); foreach ($pages->find("template=surgery, sort=parent.name, sort=name") as $category) { $category->title = $category->parent->title . ' / ' . $category->title; $options->add($category); } $options->add($pages->find("template=blog-category, sort=name")); return $options; This results in a nice, alphabetised list such as: Surgery Category A / Procedure 1 Surgery Category A / Procedure 2 Surgery Category A / Procedure 3 Surgery Category B / Procedure 4 Surgery Category C / Procedure 5 Surgery Category C / Procedure 6 General Category A General Category B General Category C and so on, so the surgery pages are in the format {parent.title} / {title} in the Select list, and the blog-category pages are just the normal {title}, all ordered alphabetically by parent (where necessary) and page title. Nice and easy

I skim-read all 6 pages - seems to be a few old bits, some bits that are maybe still issues but not sure (works for me?). A lot of issues seem to be potentially different servers whilst some are UI perhaps but it's hard to tell. I'm easy - I've made sure I've bookmarked it now - but maybe having it in the modules directory will bring more people to help as well as more people to ask questions? I can understand your hesitation though - could be a lot of new questions!

All of these have a "Release State" of Alpha: http://modules.processwire.com/search/?q=alpha so there are a few there already. You're right, it would give it more attention, but isn't it at a stage where it is preferable to use this instead of the older Thumbnails module? Out of a choice of one or the other, if this fixes things that are broken in Thumbnails module I would rather use this one I'm not sure what bits you are referring to when you say there are parts that need finishing? It seems to fit into the UI just fine from what I can see.