teppo

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?

When I started working on my first ProcessWire site I liked that by simply opening the basic-page.php template file (obviously connected to basic-page template), I could instantly see how everything worked. It was easy to start from there, building more complexity and adding those "advanced tricks" if/when needed. Things like delayed output, appendTemplateFile/prependTemplateFile, etc. raise the bar of entry, that's just how it works. They're things you won't simply "get on the first sight". You'll have to dig through other template, config and README files (or docs) to understand what's going on. However you look at it, things that "just magically do something" may be helpful and ease your workload once you understand how they work, but also tend to add to the frustration a new user feels getting used to the system. Personally I believe that the "first dive" into a new system should be as easy and enjoyable as possible. Anything that complicates things is likely to increase the bounce rate.

@sunlix: you might want to take a look at how I've handled this issue in the Changelog module. The approach I took there was adding new configuration option ($this->schema_version, which refers to the schema version currently used) and a constant (SCHEMA_VERSION, which refers to latest available schema version) and until those match it'll run updateDatabaseSchema() method, which takes care of schema updates. In that case the install routine actually uses an "outdated" schema version, so that module update (on existing installation) and fresh module installation behave exactly the same. That's definitely a question of preference. This is actually a simplified version of ProcessWire's own SystemUpdater.. and pretty much what @netcarver mentioned above too