teppo

@pwired: there seem to be a few misunderstandings here. First of all, if I suggest a specific platform, and explain my choice properly, and that makes the client lose her trust in me, I don't think there ever was any proper trust there. Just like Pete said, you just can't help everyone. About your other point, I never said that the project is doomed if the client decides against ProcessWire. I said that the project is probably doomed anyway if the client doesn't trust me and my expertise. There's a huge difference there. If a client approached me and told me that she needs to put a static one-page flyer online, I wouldn't spend a whole lot of time explaining why that flyer should be built using ProcessWire. I'd go with a static page and that's it. Also, if the client requested a huge e-commerce site, I would probably explain that there are other solutions, including various SaaS products, that probably match her needs better. Being an expert doesn't just mean that you can convince anyone to buy anything. It's about finding solutions, and sometimes the right solution is to let the project (or the client) go

@pwired: I communicate with clients regularly, and the clients I work with tend to understand common sense. They don't have to be professionals to understand that system X might not be the best choice for them because a) it's not scalable, b) it's not secure, c) it's not powerful or d) it's going to be bloody expensive. The client does have to trust my word as an expert, though.. and if there's no such trust, the project is pretty much doomed anyway

Someone else might have a better solution, but the options I can think of right now would be using a "dynamic" RewriteMap -- or a static one, if it's possible to list all the URLs available at the legacy site. On the other hand, if you end up with a dynamic RewriteMap, I'd probably go with a simple module that hooks into page not found and checks there if the requested URL exists, perhaps combined with some sort of internal caching Either way, using this kind of approach you will need to perform an additional query behind the scenes to see if the URL exists. While that's doable with -U in mod_rewrite too, it doesn't handle 404's (or, rather, it considers them "existing URLs") so it's not really useful here AFAIK.

The main "selling points" for ProcessWire I've used in the past are flexibility, cost-effectiveness, security, performance and scalability. The order depends on the client and his/her specific situation, but there's always something you can use: If the client wants something large or very specific but doesn't have an endless amount of cash to spend, ProcessWire is a very good choice, as it has built-in a lot of common features and the rest (ones that probably won't fit any pre-made solution anyway) are usually much easier to build than with certain other systems. If the client isn't entirely sure about his/her needs and/or those needs might change in the future, it's good to explain that with ProcessWire there's always room for growth. I've never, ever said "ProcessWire can't do that" (and probably never will). ProcessWire is secure, period. Zero known vulnerabilities, built-in CSRF protection, various security measures against things like cache poisoning and session hijacking, *almost zero possibility for SQL injections*. With or without the buzzwords this should be of interest to the client regardless of their technical know-how. ProcessWire comes with a whole collection of native caching methods and has pretty awesome level of performance even without any caching at all. If the client is worried about how the system will hold, toss in ProCache (or simply mention that it's easy to setup later if such a need comes up). I've managed sites with tens of thousands of pages and I know that there are a lot bigger sites than that. I'm not sure about EE, but I wouldn't even dream of doing something like that on certain other systems. Not sure if this really applies to your client in this case, but it's good to keep in mind anyway ... and, of course, there's the "it's 100% open source" thing. Many clients seem to value that nowadays.

Gamified CMS. Cool

That's what you get for answering in haste

Could be related to session fingerprinting, which is tied to IP address, so if that suddenly changes it might cause issues; you can try turning this off via /site/config.php. Just note that it's a security feature and you don't want to turn it off unless you really have to.. This thread contains couple of other things you could try.

There was one topic mentioning issues with MAMP and Yosemite, but apparently those issues are fixed in latest MAMP versions. Haven't upgraded my Mac yet, mostly because Apple seems to have pretty bad track record with their upgrades working right out of the box.. which is kind of sad since Yosemite also fixes a bunch of security issues. By upgrading you're securing your system, but with the risk that things stop more-or-less randomly working

Joss: the colours idea should appeal to Pokémon fans, at least. Just saying Anyway, just to continue where Joss left off, it's also kind of difficult to say what would appeal to groups like "business executives" in general. I know business executives who are musicians, athletes, artists, racing drivers, and so on -- they don't necessarily identify with their job title, many of them have something else they are (even more) enthusiastic about. If we do go with some sort of nicknames, I think it should be, first and foremost, something that fits ProcessWire itself.. and also a topic Ryan should have the final say on. On a slightly related note, personally I've always liked the nicknames Ubuntu has, even though I'm having hard time imagining who they were thinking while naming 14.10 "Utopic Unicorn"..

Was going to mention this earlier but it slipped my mind, so: Nico, what's your take on the storage method this module uses (saving all content to module config, i.e. the data column of related Modules table entry) and the obvious limitations it causes? Based on some quick testing, using suggested description length, this module should be able to store data for roughly 300 pages -- though actual number depends a lot on the stored data itself. I was just wondering if it would make sense to reconsider the storage method, offer an alternative method for large sites, mention this somewhere.. and/or perhaps make the module aware of how much "quota" it still has? I'm asking 'cause this seemed like an interesting choice for some of our sites, but it's not that rare for those to have hundreds or even thousands of pages.. so if the client ever gets too enthusiastic, there's going to be a problem Also: you might want to add garbage collection for removed pages. That's going to limit the scope of aforementioned scalability issue a bit.

Nico: thanks, this looks interesting! Testing it right now, so might have more comments later, but first things first: you might want to add some isset-checks to module config. Seeing quite a few notices and warnings before saving module config. Sorry, forget that, it's not about config. The problem is occurring in init(), when trying to check for $this->page->template. While viewing the module settings, $this->page doesn't seem to be available yet, which is causing some issues Edit: here's a diff for changes I had to make locally to get this module running. Wouldn't work at all before that, possibly because I've got debug mode on. Not sure if they're all required, implemented the way you'd want them, etc. and some of them might be specific to my environment. Also, moving the hooks from init() to ready() should ensure that API is ready by that time, but it could cause other (potentially unwanted) side-effects.. diff --git a/MarkupSEO.module b/MarkupSEO.module index fecc6a3..c2ebb86 100644 --- a/MarkupSEO.module +++ b/MarkupSEO.module @@ -57,7 +57,7 @@ class MarkupSEO extends WireData implements Module, ConfigurableModule { * Initializing the hooks * */ - public function init() { + public function ready() { $this->addHookAfter("ProcessPageEdit::buildFormContent", $this, 'addSEOTab'); $this->addHookBefore("ProcessPageEdit::execute", $this, 'saveSEOTab'); @@ -85,9 +85,10 @@ class MarkupSEO extends WireData implements Module, ConfigurableModule { $page = wire('pages')->get($this->config->input->get->id); $pageData = $this->getPageSEO($page->id); $configData = wire('modules')->getModuleConfigData($this); - $mixedData = array_merge((array)array_filter($configData), (array)array_filter($pageDataDefault)); + $mixedData = array_merge((array)array_filter($configData), (array)array_filter($pageData)); + $this->modules->get('FieldtypeFieldsetTabOpen'); $field = new InputfieldFieldsetTabOpen; $field->name = $this->prefix."meta"; $field->label = $this->_('SEO'); @@ -158,6 +159,7 @@ class MarkupSEO extends WireData implements Module, ConfigurableModule { $e->return->add($field); + $this->modules->get('FieldtypeFieldsetClose'); $field = new InputfieldFieldsetClose; $field->name = $this->prefix."meta_END"; @@ -204,7 +206,19 @@ class MarkupSEO extends WireData implements Module, ConfigurableModule { */ private function getPageSEO($id) { $dataOrg = wire('modules')->getModuleConfigData($this); - return $dataOrg['pages'][$id]; + if (isset($dataOrg['pages']) && isset($dataOrg['pages'][$id])) { + return $dataOrg['pages'][$id]; + } else { + return array( + 'title' => '', + 'keywords' => '', + 'description' => '', + 'image' => '', + 'canonical' => '', + 'robots' => '', + 'custom' => '', + ); + } } /**

First of all, you really shouldn't try to do an import via phpMyAdmin. Using ProcessWire's API is always a better (and easier) way. Direct SQL import is going to be a lot of work and might cause all sorts of unexpected issues, some of which you might not notice until it's too late. Import scripts are easy to write -- usually the hardest part is getting data out of the other system and, of course, planning your new data structure. I'm not familiar enough with MODX to know how easy or hard it's going to get data from there, though, but I've done my fair share of import scripts for other systems. Usually the easiest method is exporting data from original system as CSV, JSON or something else that's "machine readable" and then writing a simple import script using the bootstrap method, but there are other methods too. You might want to check out this case story -- and perhaps ask some questions in that thread too -- as it seems to have some similarities with your case. Also, if you can get your data out in CSV format and it's not too complex in structure, Import Pages CSV just might do most of the work for you. Migrator tool built by Adrian is somewhat related too, though that's not exactly off-the-shelf solution for this particular situation (there's a WordPress migrator available, but not one for MODX yet, at least as far as I know). Hope this helps a bit.

Can't speak for everyone here, but I won't be using them anytime soon. Short opening tags depend on a PHP settings in all PHP versions, so they're never guaranteed to work. While short echo (<?= $whatever ?>) is generally speaking more acceptable -- after all it's always enabled in PHP 5.4+ -- it might not work in all setups using earlier PHP versions. By the way, the accepted answer to this Programmers Stack Exchange question has a simple chart about using the short echo tag. Since ProcessWire officially supports PHP 5.3.8, I would suggest avoiding them in your modules, even if just to be consistent with the core system itself.

If the problem is that you're getting too many results, have you tried using other operators, such as *=, instead of %=?

This is just an idea I've been playing with a while: adding support for SOUNDS LIKE operator. I'm not sure how much sense it makes in the larger context, but I'm posting it here nevertheless in case it results in something useful As a bit of a background, in MySQL SOUNDS LIKE is just a shortcut for comparing two strings passed to SOUNDEX() and as Wikipedia kindly explains, "soundex is a phonetic algorithm for indexing names by sound, as pronounced in English". In other words, SOUNDEX() converts a string to an "index" of sorts, and comparing index values of two separate strings answers the question of "do these two sound alike (in English)". SOUNDS LIKE works best with English words, and literally words, since comparing entire sentences is often much less sensible (there's no native "wildcard soundex operator" in MySQL) -- names of people, products, countries, cities, etc. are a good example where one might benefit from SOUNDS LIKE. Cases I've really wished this would've been possible have included especially name and city searches, where people tend to mistype things a lot. Yesterday I decided that this would be a cool experiment, so I applied following hack to the DatabaseQuerySelectFulltext.php and Selector.php, making "€=" the SOUNDS LIKE operator. This is wrong at many levels, but works as a simple proof of concept: diff --git a/wire/core/DatabaseQuerySelectFulltext.php b/wire/core/DatabaseQuerySelectFulltext.php index 9c6064f..421f38a 100644 --- a/wire/core/DatabaseQuerySelectFulltext.php +++ b/wire/core/DatabaseQuerySelectFulltext.php @@ -83,6 +83,12 @@ class DatabaseQuerySelectFulltext extends Wire { $query->where("$tableField LIKE '%$v%'"); // SLOW, but assumed break; + case '€=': + $v = $database->escapeStr($value); + $v = $this->escapeLIKE($v); + $query->where("$tableField SOUNDS LIKE '$v'"); // SLOW, but assumed + break; + case '^=': case '%^=': // match at start using only LIKE (no index) $v = $database->escapeStr($value); diff --git a/wire/core/Selector.php b/wire/core/Selector.php index 31748f9..fccfe8a 100644 --- a/wire/core/Selector.php +++ b/wire/core/Selector.php @@ -204,6 +204,7 @@ abstract class Selector extends WireData { Selectors::addType(SelectorLessThanEqual::getOperator(), 'SelectorLessThanEqual'); Selectors::addType(SelectorContains::getOperator(), 'SelectorContains'); Selectors::addType(SelectorContainsLike::getOperator(), 'SelectorContainsLike'); + Selectors::addType(SelectorSoundsLike::getOperator(), 'SelectorSoundex'); Selectors::addType(SelectorContainsWords::getOperator(), 'SelectorContainsWords'); Selectors::addType(SelectorStarts::getOperator(), 'SelectorStarts'); Selectors::addType(SelectorStartsLike::getOperator(), 'SelectorStartsLike'); @@ -284,6 +285,10 @@ class SelectorContainsLike extends SelectorContains { public static function getOperator() { return '%='; } } +class SelectorSoundsLike extends SelectorContains { + public static function getOperator() { return '€='; } +} + /** * Selector that matches one string value that happens to have all of it's words present in another string value (regardless of individual word location) * Just for fun I've been testing this new operator with a script like this (and using one of the most mistyped names I've seen on this forum as a test subject), to see if it works at all: <?php require 'index.php'; foreach (wire('pages')->find('title€=antti') as $k => $p) { echo $k . ". " . $p->url . "\n"; } // results look something like this: // 0. /anttti/ // 1. /antti/ // 2. /anti/ // 3. /antii/ So, what do you folks think -- is there anything in this that might be worth taking further? Can you think of a better approach to this, such as a custom fieldtype with SOUNDS LIKE support, or something? Anything else?