netcarver

I would guess this is down to row level locking in InnoDB over full-table lock in MyISAM. @Sevarf2 There is another option for handling a large number of simultaneous sessions: Redis. Your server sounds like it would be well specified to run redis too, though if it's now working well in production with InnoDB tables, I'd be tempted not to change it.

@NorbertH Out of curiosity, how long does your script take if you don't actually save the page? <?php namespace ProcessWire; include "index.php"; // Include PW include "berufe.php"; // Simple array with about 25000 Job names /* $berufe = array( array('id_beruf' => '1','berufsbezeichnung' => 'Aalbrutzüchter/in','kldb2010' => '11412'), array('id_beruf' => '2','berufsbezeichnung' => 'Aalfischer/in','kldb2010' => '11422'), array('id_beruf' => '3','berufsbezeichnung' => 'Aalräucherer/-räucherin','kldb2010' => '29242'), ... */ foreach ($berufe as $beruf){ echo $i++. " " .$beruf['kldb2010']." ".$beruf['berufsbezeichnung']."\n"; $p = new Page(); $p->template = 'berufsbezeichnung'; $p->parent = '/einstellungen/berufi/'; $p->title = $beruf['berufsbezeichnung']; $p->schluessel = $beruf['kldb2010']; //$p->save(); } ...and... <?php namespace ProcessWire; include "index.php"; // Include PW include "berufe.php"; // Simple array with about 25000 Job names try { $database->beginTransaction(); foreach ($berufe as $beruf){ echo $i++. " " .$beruf['kldb2010']." ".$beruf['berufsbezeichnung']."\n"; $p = new Page(); $p->template = 'berufsbezeichnung'; $p->parent = '/einstellungen/berufi/'; $p->title = $beruf['berufsbezeichnung']; $p->schluessel = $beruf['kldb2010']; //$p->save(); } $database->commit(); } catch(\Exception $e) { $database->rollBack(); } ...? Should give us a handle on the overhead of creating 25000 pages and setting the data on your test system.

A very simply library that quickly allows localisation of country, language and currency names into various locales. It's based on the data from Umpirsky's country-list project. I started writing this back in 2014 but have finally got around to publishing it. I hope this is of use to some of you. Usage Examples... To create a localisation for a particular locale, first create a new instance and define the locale... $de_DE = wire('modules')->get('LibLocalisation')->setLocale('de_DE'); You can now use your locale to get information about countries, currencies and languages as they are used in that locale. For example, to output the names of various countries you use the country() method, passing in an ISO 3166-1 2alpha country code... echo $de_DE->country('CH'); // Outputs "Schweiz" - the German for Switzerland. echo $de_DE->country('AU'); // Outputs "Australien" - the German for Australia. echo $de_DE->country('US'); // Outputs "Vereinigte Staaten" - ditto for the United States of America. You can create as many instances of the module as you need and set them all up for the same, or different, locales. To access currency data, you call the currency() method, passing in the 3-letter currency code you are interested in. echo $de_DE->currency('GBP'); This returns an array of data about GBP - localised in German... [ digits => 2, number => "826", symbol => "£", name => "Britisches Pfund Sterling" ] Finally, you can output localised language names by calling the language() method and giving it a 2 letter language code. echo $de_DE->language('fr'); // Outputs "Französisch" - the German for French. Getting the Module... You can view the project on Github or in the module repository.

On the to-do list for the next version, is localisation of the input and output country names in the country select list (again thanks to @matjazp). To do this, I plan to release a module that I wrote for a different project back in 2014, but never got around to publishing: LibLocalisation. (It needs a little tidy-up first, as PW has progressed a long way since I first wrote it.) This module allows simple localisation of country names, language names and currencies. The Street Address module will leverage this, if it happens to be installed, to display the select list of countries in the language being used by the user's browser - and to localise the destination country name into the language(s) used in the origin country as this is the language that postal workers in the source country will be used to. There will be extra config options to control this. Following that, I plan to work on @thlinna's request to make this work with FormBuilder. Update:

Thanks to @matjazp, I've just pushed 1.0.6 which allows you to include the destination country ISO in the output if needed.

@thlinna it's definitely a compatability issue. I will need to research how to get this working with FB. Could take a while. In the meantime, version 1.0.5 is out.

I think current incompatibility is more likely than a PEBCAK issue. ?

@thlinna I have not tried this in FormBuilder yet, though I have tested it in a Repeater Matrix setup. I also know it is not yet compatible with being placed in the User template and accessed by a user from the Profile editor - though when editing the user page from the normal page editor, it works just fine. @adrian Thanks for the script example!

Hi @thlinna Thank you for your kind words. Regarding importing data: is your current data... A) in a single textarea field? B) in a set of text fields? If the answer is A), then is each address in exactly the same format? If so, then you could write a custom import script. If the answer is B). then you could write a custom import script - and it would probably be easier than the first case. There is nothing built in to the field to do this for you.

@arjen Thank you for explaining! For what it's worth I use the StreetAddress field in a repeater matrix for a contact DB in the charity I originally wrote this for, and it works very well. Also, if you want to output an address in different ways - including the Postal format of the destination country - then StreetAddress does allow that too. Now, this may not be applicable to your situation, but in the case of the charity, they have to send letters so the postal format is needed (multiline, some fields have to be capitalised etc), but the same address data can appear in their letterhead and footer formatted in a totally different way (single line, using title-case rather than uppercase town names etc.) This is really easy to do using StreetAddress but would be difficult to do using a single textarea for an address. Formatting of the charity address can be similarly tweaked for outgoing email.

I am curious about the word used for the country in @matjazp's last example: "Schweiz" which, I assume, is Switzerland (CH). However, this is not what I would expect Switzerland to be called in Slovenia. In the past I've used Umpirsky's country code localisations. In them, the Slovenian word for Switzerland seems to be "Švica" and not what was used in that example. So, If the example is correct - which it probably is - then it means my assumption that I should use the language of the originating country to spell the destination country in the address is wrong, and the inputfield needs to allow for this. Would anybody care to comment on this? @arjen Thank you for the feedback, glad the JS problem is resolved. Curious about your meaning here... ...could you expand on this a little? Best regards, Steve

@matjazp Just took a second look at your examples. I see that the last one is international - and that I need to do some more work with regard to using the localised language name for the destination country. Will add this to the to-do list.

I've just pushed version 1.0.4 that should fix the persistence of your custom override files between updates. Adrian has also pointed out that this could be brought into the module config settings - something that I will consider for a later release. Please let me know if your custom formats_overrides.php files are not being successfully persisted between updates. Thank you!

Hello @matjazp The metadata for postal formatting of the addresses comes from Google's libaddressinput project. I note that the "SI-" prefix to the Slovenian postal code is actually coming from Google's postal address format metadata for Slovenia. Please reference line 1324 of the formats.php file and you'll see that "...%nSI- %Z..." appears in the format string. This forces the literal "SI- " to appear at the start of a new line, just before the zip/postal code. Essentially this is an upstream library issue and you can open an issue against libaddressinput to attempt to get it resolved, though I note there is an old, closed, issue regarding the prefix to the Slovenian postal code. However, I anticipated situations like this and there is a mechanism built in to the module code you can use to override the upstream format. If you edit your local copy of formats_overrides.php and add the following to the returned array, you will be able to customise the format as you require until Google fixes (or doesn't) the upstream repo... 'SI' => [ 'fmt'=>'%N%n%O%n%A%n%Z %C', // Prevent "SI - " from prefixing the postal code. ], The metadata for Slovenia marks non of the fields as mandatory - so you should find this input works for you as is. In fact, from version 1.0.2, you need to rename the example.formats_overrides.php file to formats_overrides.php as I am currently working on making the installed overrides file persist across upgrades (something it doesn't do quite correctly yet.) Also; just in case you haven't worked out how to suppress the country in the input and output of domestic addresses, you should be able to do so by setting the config options for the street address field as follows... Allowable countries: select just Slovenia. Show destination country field?: Set to "Never". Regarding benefits over a free-form textarea, here are some I can think of... Address subfields can be used in PW selectors: $addresses = $pages->find('address.locality=Paris'); Automatic compliance with layout requirements (including capitalisation and required fields) of the destination countries postal format (where correct in the meta data). Slovenia seems quite relaxed in which fields are required and which should be capitalised. Many European countries require certain fields, and require them to be output capitalised when used as postal addresses. Aids data cleaning on input over a free-form textarea (lots of my users type with caps-lock on, for example!) Automatic zipcode/regex application to subfields. Direct access to subfields, if you want to use them in your own template output other than in a full address label. Assorted format() functions for single/multiline, plain/html output. Automatic inclusion of address microformat metadata to the fields. I did read various UI/UX forums about this issue before I started, many of them came to the conclusion that a free-form input is best from the UX point of view - and I can understand that point of view. This module is my attempt to meld as close to a free-form input experience as I can, with structured data that accepts just about any country's postal code format. I hope that helps. Best wishes, Steve

@arjen I've uploaded version 1.0.1 that should fix the JS error you reported. Regarding the Postal Code, the cached Dutch address metadata (look in the formats.php file for the "NL" entry) does have a regex for the post code - so this should be checked and an error shown for non-matching input. Once you've installed version 1.0.1, could you please test it again. Regarding the corrections of capitalisation, those should be shown when you click on the "?" icon. Were you clicking or just hovering over the "?" before?

Ah, yes, that should work. Will take a look this evening. Thanks for the clarification.

@arjen Thanks for the report - I'll look at fixing your JS report tonight. Regarding spelling, no. I do not have any spellcheck control set on the fields, so whatever spell-checking your browser normally does should be applied to those fields. Also, there is no ajax postal code -> city lookup going on, so if you are expecting that, you'll be disappointed. However, postal codes should be checked as long as the dutch meta-data from google includes a regular expression for that field. Again, I'll check when I'm free tonight.

@arjen Thank you, I spent some time tweaking the inter-field delete. I am aiming for something that seems nearly as free-form as a textarea, yet is more guided. How's it working out for addresses in the Netherlands? Is the layout as you'd expect?

This module has just been made public under a MIT license. The opening post has been updated to reflect its release.

@Soma I would expect a 40k row -> 40k page import to take a while - but a simple sync with only a low % of rows changed should be pretty fast. Of those 40k rows, approximately how many of them change between each cycle? I'd be tempted just to have a script do a diff between the last version and the current version and then only process the rows that have some kind of diff. Should be much faster that way if only a small set of rows change each cycle.

Hi @adrian, just noticed I'm getting this warning with debug mode on for a site I updated to the latest version... ( ! ) Warning: Illegal string offset 'value' in <snip>/site/assets/cache/FileCompiler/site/modules/CookieManagementBanner/CookieManagementBanner.config.php on line 109

@Jan235 You could also try out the TextformatterFluidImages module that does some of what you are after (setting custom classes) and perhaps modify it to add the srcset attribute if it is going to be the same for all images in the CKEditor inputfield.

Anyone planning on doing a U2F compatible 2nd factor module?

Any resources showing as not loading in the network analysis tab? Any errors in the console tab?

@Krlos If you come up with a set of steps that is reproducible, please open an issue on the processwire-issues repository reporting it. Thank you!