marcus

I think the "name" database column on pages is special, and your same approach to the title field of a page should work perfectly. "name" field serves as URL alias, and therefore needn't contain special characters in order to not break URLs. I'm not sure on the search issue. Maybe connected to the way MySQL searches?

Since you are working locally, check your local environment for Xdebug.max_nesting_level setting: http://xdebug.org/docs/all_settings#max_nesting_level

http://www.visitwales.com/ has a very similar one and uses Flexslider v2.1: http://www.woothemes.com/flexslider/

Hi Hari, you're right - I read them back in 2013, but forgot until now - thanks! Composer could be the solution here regarding dependencies I'm also very interested in how PW3 will support it. The last PW blog post on this topic reads promising!

Welcome, justb3a and clsource, as core contributors to wireshell! We got a dedicated GitHub organization now: https://github.com/wireshell/wireshell - please update the remotes of your forks Packagist reference is already updated, to the usual $ composer global require wireshell/wireshell will work like before. The three of us are now toying around ideas how to improve wireshell, and one big feature would be if ProcessWire modules could provide their own wireshell commands (in addition to the wireshell core commands). We're not sure how to do this exactly, but maybe the PW community/module authors have ideas. Our current scenario: Besides from scanning its own /src/Commands folder for core commands (right now commands are hard-coded in /app/wireshell.php), thanks Stikki for the idea!, wireshell could search inside (ProcessWire's) /site/modules/ folder for commands provided by modules. So for example, alongside /site/modules/MyAmazingModule.module there can be a MyAmazingModuleCommand.php file (or commands, or "namespace" folder if there are more than one). The things bugging me here are a) dealing with dependencies and b) the exact details of "scanning for commands". But maybe someone could chime in here? I guess a concept of "PW module provided wireshell commands" would be a huge step forward (Drupal's drush already works this way, and makes it a really, really useful tool)

I can imagine how overwhelmed you feel right now. It's like wanting to start playing the guitar, but being confronted with amplifier settings, guitar brands and whatnot right within the first minutes. When you only want to learn one single chord first and build upon that. I guess you already stumbled upon Chris Coyiers close-to-perfect intro to Grunt? http://24ways.org/2013/grunt-is-not-weird-and-hard/ ? My advice would be: Choose either Grunt or Gulp (both are great, capable, and have all necessary functions as plugins), stick to that decision for a couple of projects, don't let distract yourself by the usual developer tiffs, and once you build your own Grunt/Gulp boilerplate and feel confident with it, reach out for optimizations (and maybe read these links here again). But then you'll already have entered the amazing world of task runners and will most probably consider them as a crucial part of your development workflow Also, here's a super simple Gulpfile from processwire-recipes.com, just dealing with SASS and gluing some JS files together (Please ignore the messed up indentations in the file)

Regarding this permissions-after-upgrade-issue, I just pushed a prompt to dev branch as you've suggested, b3a. I'm still not sure whether I just tailored it for my setup and it's issues, or MAMP usage in general. Anyway, it should not hurt the command to have it there.

Right, must have skipped that part while reading