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/

My pages_path table has a path field with ascii_general_ci collation. So the German Umlauts can not be stored in this field. In the page_path_history table the 'path' field is utf8_general_ci - which is fine for the Umlauts. Skipping the page-path module leaves me with the pages table and the name field, which is also ascii_general_ci. What is the best way to handle this situation?

Thanks Horst, but that didn't cure the problem. I have page-path-history installed. First I deleted the relevant entry in the database, then I even uninstalled the modul - no help. But then I tried something other. I was working on a local XAMPP version, getting the problems. I've uploaded a 1:1 copy to my webserver - and here it worked! So obvious the local system behaves differently to the remote server - who knows why.

this happens actually on ProcessWire 3.0.9 devns. I've deleted a content page (cleared trash bin, cleared browser cache) . Then I created a new page that should end up with the old URL (that of the previously deleted page). As the page title is the same - the URL should be the same. But when storing, a session alert says: 'already in use' and a slightly modified URL is created. I've searched the database for any hints -but I could not find one. What need's to be done to re-use historic URLs (of deleted pages) ?

@Peter: duplicate content is not an issue as you also need to have a canonical link on the AMP page, directing to the 'full' page. So Google is fully aware of the two pages - they actually asked for a 'separate mobile content', didn't they? Basically nothing really new. There were days when we had seperate mobile sites, and our server selcted what content to be sent out. Now again we have two different offerings/pages, and Google does the pick.

@LostKobrakai: Danke! Google can find the AMP page via a link you should place on every standard-page (directing to its AMP-sister). More info on this: https://www.ampproject.org/docs/guides/discovery.html The remark on the Wordpress plugin was more a 'political statement'. If it is very easy for the millions of Wordpress users to make use of AMP they will use it. As Google stated they will favour AMP sites in mobile SERPs from now on I think it is worth to keep an eye on what is going to happen in the near future.

I think PW should offer a solution (module?) for AMP as the big WP already published a plugin. Google is pushing the AMP project as they pushed for https/spdy/. Now we got Let's encrypt (certificates for free). If we like it or not - Googles market share in search is (at least here in Germany) >90 % - so ignoring their moves is heroic but cuts you off the line. As I understand we have to offer two versions of one page, a regular one and a AMP-Version. Depending on the the requesting hardware (phone/tablet/desktop) Google (or any other search machine?) offers the appropriate page in the SERP. This leads to two different templates for a page, two URLs and a crosswise linking of the pages. So what would be needed in PW is the ability to assign a second (plus third,plus...) template to the content page, where each template is assigned a separate URL (or prefix/suffix) . As I am not a coder I'd appreciate the help of the community.

@peter I had the same issue on a Plesk server. But I found a solution here https://github.com/plesk/letsencrypt-plesk/issues/13 A little down the list, what xgin commented 29 days ago (put a special .htacces file into a directory). You also have to take care of the rights the directories need (tofi86 commented 17 days ago). Then you can keep your original .htaccess and it will (hopefully) work automatically when the renewal of the certificat is due.

Solved - my fault -sorry: This was wrong $dateFormattedDatum = strftime("%d.%m.%G", $date); this does it correct: $dateFormattedDatum = strftime("%d.%m.%Y", $date);

I have a couple of datetime fields wrapped in a multiplier field. I put in 02.01.2016 , the output is 02.01.2015. This happens only up to the 3rd of January 2016, with the 4th of January the output is okay again (04.01.2016). Checking the database entry shows the correct date (02.01.2016). See also the attached picture of the input, database and the output. Any idea what's happening here?