Werner Pilnei

Found it - reading the docs is almost every time helpful. It is in the 'requirements array' // Currently the requirements array only holds the query min length argument. 'requirements' => [ 'query_min_length' => 3, ],

I need to find words like 'Au' or 'Öd' (which are the names of small villages in Germany), but the standard requires a minimum of 3 characters in the search field. I changed the mysql.cnf setting to innodb_ft_min_token_size=2 ft_min_word_len=2 but with no luck finding them via Search Engine. Any idea where to tweak ? Thanx

I've checked the network panel and it looks the files are coming from cache ( I have files with 'from service-worker' and with a little gear-wheel symbol). I also have checked your page with my Chrome browser and I saw the OK for the requests. So there is definitely a difference. But doing this comparison between your and my installation something more 'shocking' grabbed my interest. The first request (for the HTML) shows a significant 'stalled' time - waiting and doing nothing like a hick-up. This is about 500ms on your page and about 300ms on mine. If this is the price for the service-worker I think it would be a bad 'improvement' - but I am still positive that it is just the struggle with a brand new technology and we will find out who is pulling the brake.

Thanks Johannes for the module. I got it running , but checking with the dev tools in Chrome I got no 'OK' in the response column for the requested cache items (see picture). Looking at https://developers.google.com/web/fundamentals/getting-started/codelabs/your-first-pwapp/ they show a 'OK' in that column. So I am not sure whether the caching works correctly or not. (Update: In Firefox Dev edition it shows OK for the responses)

@Nurguly Ashyrov Hello Nurguly, I was following this thread from day one and I am deeply impressed by the passion you are putting into your 'baby'. Especially your in-depth explanations helped me understand your concept and getting first results on my own. Very often talented programmers do not have the same skill in teaching others . But you definitely have. Right now I am experimenting with your module to figure out if this could be a method to be used in a PWA (progressive web application). Using the GraphQL channel I would reload just my 'new' data via the service worker . Therefore it wouldn't matter that this data is exposed to the public - it should go there anyhow.

@adrian I am sorry but I am no longer using the module - my customer didn't want to use the functionality and so I removed it. Thank you guys for your efforts in helping me out.

Unfortunately it didn't help, Adrian. Looking at the Flourish web page I got the impression that this is a 'dead' project - the jungest blog entry is from 2012, also the forum has latest activities from 2013. That PHP 7 might have issues with these classes is probably not too strange. The fMailbox.php also indicates an age of 4 years.

@adrian Yes, the site is on https. Calling the standard url does not help - as the site rewrites it to https and I can't figure out how to reset it to not rewrite it . As I have no need to go to PHP 7.x - it works with https and 5.5.9 perfectly - I can live with the status quo. Thanks for looking into that issue.

I went from PHP 5.5.9 to 7.07 (on PW 3.0.22, Process Email to Page 1.1.9) and got a cron issue right away (before it was working perfectly). This was the error message: Error: Exception: There was an error connecting to the server. A secure connection was requested, but was not available. Try a non-secure connection instead. (in /var/www/vhosts/aic-info.de/httpdocs/pw/site/modules/ProcessEmailToPage/flourishlib/fMailbox.php line 969) #0 /var/www/vhosts/aic-info.de/httpdocs/pw/site/modules/ProcessEmailToPage/flourishlib/fMailbox.php(1199): fMailbox->connect() #1 /var/www/vhosts/aic-info.de/httpdocs/pw/site/modules/ProcessEmailToPage/ProcessEmailToPage.module(439): fMailbox->listMessages() #2 /var/www/vhosts/aic-info.de/httpdocs/pw/wire/core/WireHooks.php(619): ProcessEmailToPage->importFromEmail(Object(ProcessWire\HookEvent)) #3 /var/www/vhosts/aic-info.de/httpdocs/pw/wire/core/Wire.php(370): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Page), 'render', Array) #4 /var/www/vhosts/aic-info.de/httpdocs/pw/wire/modules/Process/ProcessPageView.module(205): ProcessWire\Wire->__call('render', Array) #5 [internal function]: ProcessWire\ProcessPageView-> ------------------------------------------------------------------------------------------------------------------ Adding the "/dev/null 2>&1" to the unique URL did not reproduce the error message, but it did also not fetch the mail from the mail box. As switching back to PHP5.5.9 cures it there seem to be glitches when using PHP 7.x

I was using Ryan's suggestion (#2) and it worked quite well until I added a new tag to my list. This one was added to the alphabetically sorted list at the end, inspite it was a 'a...' word- which should be on top of the list. It looks that the [key] of my $tagCloud array is using the tag ID, and when sorted they will just result in an sequential row of the IDs.Originally I had imported all Tags, ordered alphabetically- so the issue was not obvious up front. How can I use the $tag->title for sorting?

Adrian, I am sorry for misleading you with the 90% figure. It just describes my success in transferring Drupal data to ProcessWire in an automated way. The BCE module (thanks for that) is doing 100% what it should, the field pairings work great. My missing 10% is that I have to unwrap Drupal field collections into single fields for ProcessWire. I can do that probably on the CSV side and split the columns into fractions.

Same effect on 3.0.15, but some strange 'extra' effect. I modified the array 'supported fieldtypes' and added TextUnique and Time: protected $fieldtypes = array( 'FieldtypePageTitle', 'FieldtypeText', 'FieldtypeTextarea', 'FieldtypeInteger', 'FieldtypeFloat', 'FieldtypeEmail', 'FieldtypeURL', 'FieldtypeCheckbox', 'FieldtypeFile', 'FieldtypePage', 'FieldtypeTextUnique', 'FieldtypeTime', 'FieldtypeDateTime', ); After that I can select these fields in the dropdowns, but the standard fields are still not available. As I want to convert 700 pages from Drupal a working solution would be of great help. Update: I got a 90% solution with Adrian's Batch child editor - I struggled a bit finding the CSV import settings for field pairings under 'page settings'.

Horst, thank you for putting me one right track. Actually the difference was in the templates, but I couldn't see it there. There is no 'UTF-8' switch or anything like that in the templates area. I then went through my modules and found a suspect: it is called PageAutoName , and after turning it off everything was ok. Maybe it happened because this module was not approved for my actual version (3.0.12) or it just can't cope with the extended page name. Anyhow, this situation shows the crux between being 'lazy' and using these comfortable helpers (modules) and somehow losing control over the process (who is doing what). In that context it would be helpful to see on the template view which modules are influencing the process of this template. Right now you have to go through all modules and look if they are set active for which template ( or is there another way finding that out?). Thanks all for the patience!

Thanks Ryan, I verified the instructions step by step. I found two things: - my system does not like to have a whitelist in config.php - it messes up my admin layout and blocks the log-off button. As you wrote it is not necessary to have it there.-so I left it out. - secondly I tried to create a new page in my TAG area (based on another template than the 'faulty' one) - and it worked. So what we got: Template shop: Session: Achtung, der gewählte Name "ryan-krämer" wird bereits verwendet und wurde geändert auf "ryan-kramer" (..already in use, but I swear I never tried this one before) Template tag: Session: Die Seite /tags/ryan-krämer, die das Template tag nutzt, wurde erstellt (so here everything went well- it ended up in the pages table as xn--ryan-krmer-w5a) So the questions are: why do both templates act differently and what triggers the 'already in use' status of the shop template

@WillyC I started looking at the tables because it did not work. Every time I am using an Umlaut I get this message: Session: Achtung, der gewählte Name "bäckerei-testmann" wird bereits verwendet und wurde geändert auf "backerei-testmann". Saying that this name already exists and needs to be changed in a name without the Umlaut - but it is not a previously used name (it is a brand new phantasy name). I think the error message is wrong- the Umlaut just could not be written into the ascii field. If nobody else is having similar effects it is eventually just my setup - it was upgraded from 2.7x through various steps to the latest one. By the way, Soma ran into a similar (?) issue once: https://processwire.com/talk/topic/6688-illegal-mix-of-collations-ascii-general-ciimplicit-and-utf8-general-cicoercible/