Autofahrn

Edge (still same machine): True Boolean: Yes: 4998588 No: 5001412 in 3542.50002880837ms Logical: Yes: 9999775 No: 10000225 in 3009.699778367602ms Comparison: Yes: 14999604 No: 15000396 in 3001.5002759201707ms Unrolled: Yes: 19998134 No: 20001866 in 3037.500176051153ms Floor: Yes: 25002010 No: 24997990 in 4482.999860439448ms

The thread finally switched into Browser Benchmarking now. My numbers were taken from Firefox, which returns now as an integer only. On Vivaldi (Chromium) this is a float and execution times are generally longer (same machine) and Logical indeed is fastest: True Boolean: Yes: 5001949 No: 4998051 in 201.30000000062864ms Logical: Yes: 10001446 No: 9998554 in 173.00000000250293ms Comparison: Yes: 15001053 No: 14998947 in 177.5999999990745ms Unrolled: Yes: 20000397 No: 19999603 in 240.49999999988358ms Floor: Yes: 24999139 No: 25000861 in 186.0999999989872ms So watch your step when optimizing for performance in JS.

at least longish... ?

@SamC: Exactly @happywire: You are completely right except the last point: The snippet performs the boolean evaluation of Math.random() some thousend of times: var YesIfTrue = !!~~(Math.random() * 2); // Boolean result 50/50 You either get a boolean true or boolean false for each iteration. YesIfTrue is set, if the truncation of (Math.random() * 2) is equal or above 1.0 (or Math.random() returns a value equal or above 0.5). The less obfuscated version of that line would be: var YesIfTrue = Math.random() >= 0.5; Which can be unrolled to: var YesIfTrue; if(Math.random() >= 0.5) YesIfTrue = true; else YesIfTrue = false; which is what actually happens behind the scenese: A numerical comparison on two floats along with a "jump" to either assignment statement. While there still is some "jumps are bad" in many minds, that's not necessarily true for JavaScript. In fact the version using the comparison may effectively execute faster than the obfuscated "true boolean" version, but the unrolled version is slowest (10Mio iterations, Firefox 65): True Boolean: Yes: 4999123 No: 5000877 in 54ms Logical: Yes: 9997660 No: 10002340 in 51ms Comparison: Yes: 14996131 No: 15003869 in 39ms Unrolled: Yes: 19995907 No: 20004093 in 98ms Floor: Yes: 24996634 No: 25003366 in 57ms var i, cntYes=0, cntNo=0; var tStart, tEnd; tStart = window.performance.now(); for(i=0; i<10000000; ++i) { var YesIfTrue = !!~~(Math.random() * 2); cntYes += YesIfTrue; cntNo += !YesIfTrue; } tEnd = window.performance.now(); console.log('True Boolean: Yes: '+cntYes+' No: '+cntNo+' in '+(tEnd-tStart)+'ms'); tStart = window.performance.now(); for(i=0; i<10000000; ++i) { var YesIfTrue = ~~(Math.random() * 2); cntYes += YesIfTrue; cntNo += !YesIfTrue; } tEnd = window.performance.now(); console.log('Logical: Yes: '+cntYes+' No: '+cntNo+' in '+(tEnd-tStart)+'ms'); tStart = window.performance.now(); for(i=0; i<10000000; ++i) { var YesIfTrue = Math.random() >= 0.5; cntYes += YesIfTrue; cntNo += !YesIfTrue; } tEnd = window.performance.now(); console.log('Comparison: Yes: '+cntYes+' No: '+cntNo+' in '+(tEnd-tStart)+'ms'); tStart = window.performance.now(); for(i=0; i<10000000; ++i) { var YesIfTrue; if(Math.random() >= 0.5) YesIfTrue = true; else YesIfTrue = false; cntYes += YesIfTrue; cntNo += !YesIfTrue; } tEnd = window.performance.now(); console.log('Unrolled: Yes: '+cntYes+' No: '+cntNo+' in '+(tEnd-tStart)+'ms'); tStart = window.performance.now(); for(i=0; i<10000000; ++i) { var YesIfTrue = Math.floor(Math.random() * 2); cntYes += YesIfTrue; cntNo += !YesIfTrue; } tEnd = window.performance.now(); console.log('Floor: Yes: '+cntYes+' No: '+cntNo+' in '+(tEnd-tStart)+'ms');

Well, if you see your customer uses a french (or any other country except english) browser, you detect its not english and redirect to italian. Since the browser does not change, you again detect its not english and redirect...

sorry: No! Any logical operation like OR '|', AND '&', EXOR '^', Bitwise complement '~' or even shift can only be processed on integers. Using one of these operators enforce JavaScript to typecast any other type into integer. If one of the operators is a float (like return value of Math.random), then decimals are just truncated (a 1.99999 gets 1), if its a string, JS tries to convert it into an integer first. The logical OR (in contrast to the boolean OR '||') is executed in any case. Even if '| 0' does not seem to make any sense, its just there to enforce the type conversion, so the result is an integer. Using a logical operator in contrast to Math.floor basically optimizes for performance (no method call). And if you need a true boolean result and love obfuscated code, try this: var randomNum = !!~~(Math.random() * 2); Maybe this snippet helps to clarify it: var i, cntYes=0, cntNo=0; for(i=0; i<10000; ++i) { var YesIfTrue = !!~~(Math.random() * 2); // Boolean result 50/50 cntYes += YesIfTrue; // Count only true results cntNo += !YesIfTrue; // Count only not true results } console.log('Yes: '+cntYes+' No: '+cntNo);

The logical operator or still converts the result from the multiplication to be integer, kind of Math.floor(Math.random()*2). To make confusion perfect, result should be same using double bit complement like this: var randomNum = ~~(Math.random() * 2); Result is either 0 or 1 with 50/50 probability. More info about rounding/truncating here: https://stackoverflow.com/questions/596467/how-do-i-convert-a-float-number-to-a-whole-number-in-javascript

I guess the or operator | enforces a type conversion from float (return of Math.random) into integer. So left part of the or is intended to ranges from [0...2[ (not containing 2.0, since Math.random ranges [0..1[) and the result of the or is either 0 or 1. Not sure about the +1 and -1 though...

To evaluate your plain vanilla HTML form in a template, just check out $input->get() resp. $input->post() which will hold your form data (see $input API variable). Wondering if there isn't an example for a simple form around in this forum...

At least you're not alone, @gebeer: but last event is 6 months in the past on my sites.

ok, somehow mixed up that this.attr, doesn't work... To access individual fields and don't want to use JSON (any reason for that), you may inject that into your DOM tree and access relative to the parent element. That way you: - combine discrete information into some markup - deal with proper escapement of special chars etc. - send that markup to client - client needs to parse markup to retrieve discrete information (and decode handling of special chars) Using the JSON version is much more straight forward, scalable and takes care of most aspects of proper data escapement.

Is there a chance to exclude files by regex? I'm thinking about something like "\.\d+x\d+\." to exclude any image variant created from the API, for example.

Not being updated that long time may indicate something stable... ? I'm using Ryan's LoginRegister module for member registration: https://modules.processwire.com/modules/login-register/ You may create forms in a variety of ways, depending on your needs. FormBuilder is basically a wrapper around existing fields to handle the form submission like sending mails, storing form data into database or even into pages. Without FormBuilder you'll have to do this on your own. Either still using existing fields and process their input or using native HTML markup. This basically depends on what you like to provide to your users. If its pure text input, you may want to go with plain vanilla html. If you intend to provide something more complex like rich text editor, using existing fields is probably easier to handle.

Wondering if its not just: $.get(this.attr('href'), function(data) {

Did you check the PW logs (Setup->Logs->Errors)? Error 500 happens on server side not inside your JS code.

try: $(".button").click(function(event) { event.preventDefault(); // No default action

Did you check your error log for a more comprehensive analysis? Apart from the error: $("#date").html("<p>Loading...</p>"); should probably refer to #data and your template code should probably only return the part "// some images", otherwise you'll nest a new section for each button click. I case you intend to do more dynamic updates, returning a JSON instead of pure HTML may be an option:

ok, tested a little and the selectors seem to work for me, primarily tested with this one: $results = $page->children("!date_end|date_end>=$start,date<$start,sort=-date,limit=12"); Did you try outputting your date and date_end fields unformatted to see if they contain proper values?

Guess you have to compare timestamps not the formatted values: Edit: Sorry, beeing blind, you're already using timestamps...

sure, but after editing the first, the warning went away... ?

This is something I have to do each time on my virtual server and I guess it has to be done to have correct locale definitions depending on user's language choice. For each language click on "Find Files to Translate" and from the list "Translateable files in /wire/" select "/modules/LanguageSupport/LanguageSupport.module" and click submit. In the field for "C" enter the correct locale setting (something like "de_DE.utf8" for german). The exact string depends on your particular system. I know we had a topic to list installed locales somewhere... Edit: This may help: print_r(\ResourceBundle::getLocales(''));

You may try getUnformatted, something like this: $dateModified = date('d/m/Y', $page->getUnformatted('datemodified')); (adjust the d/m/Y to whatever required)

To simply backup and clone an existing install I'm used to use the Duplicator module. Works like a regular install.

Sorry to say, but when you intend to migrate fields between installs be aware that the GUI import/export functions rely on ids rather than names. If the target is not 100% in sync with the source, you may end up correcting things in the database. This is particular true when it comes to Repeaters and the RepeaterMatrix. ...and do Option fields restore options properly when importing an exported page? Until now I preferred to do this via API and run my own, application specific implementation.