dragan

@bernhard Perhaps go back to page 1 of this thread, i.e. this post. a) I have inserted in all JS files "use strict" at the very top b) I have replaced != with !== everywhere the IDE was warning me tldr; "use strict" in JS is something like PW's debug mode enabled: it gives you many more errors, hints + warnings that otherwise would slip through (even if you end up with unexpected results). The Mozilla link I posted is a good read.

@tpr There's something in AoS that interferes with the brandnew toggle fieldtype. See here for description.

@ryan No, not yet. I have only enabled a few functions. What I found strange though (perhaps just coincidence): The bottom left link "disable AoS" also stopped working as it should, i.e. I had to save module settings twice, before it was disabled. That link to disable the module has a query string parameter toggle, which is set to 1. And afaik the first toogle field-value (e.g. Yes) also has value 1. That's maybe one toggle too many :-)

OK I found the culprit: I disabled AdminOnSteroids and now toggle fields behave as they should.

No JS errors. Google Chrome, Windows. Also: When I previously selected No, then re-edit the page and select Yes, it sticks with No. It's the same with Firefox and IE11, btw. $config->debug = true; $config->advanced = true; Apache/2.4.39 (Win64) OpenSSL/1.0.2s PHP/7.2.11 Nothing supicious in Tracy.

Difficult to say with so little infos. But in any case, a DB almost half a GB big is rather... big. There are various ways how to create a DB-dump. Did you use PW's DB-backup or did you create your own? Try to delete all cache DB entries in your dump.sql first. They can become huge, and are rather useless on a new install. Then maybe delete everything inside site/assets/cache/. Do you have DB-session handler installed or default? (file-based) What was the last time the site (core) was updated? Log files (PW + server)? Did you check site/config.php? $config->debug = true; $config->protectCSRF=false; Finally... is the clone running on the exact same setup (PHP version etc.) as the original one?

Yep, I was also underwhelmed, with both services. An upscaled image (4x) showed really ugly artefacts on the face and hands parts of an image. With background-removal... well, an entire (huge) part between two body-parts was not removed (similar skin-tone and background-color). It seems that even with AI in 2019, the old adage still holds true: SISO. The better / bigger your original image is, the better output you'll get.

@ryan There seem to be issues with the new toggle field-type. I just upgraded to the latest PW dev, and installed toggle and placed in basic-page tpl. The setup is like this: On pages with No or Undecided the output of $page->toggle is what I would expect. However, on the page where I selected Yes: I get only an empty string with Tracy in the frontend. In the backend, when I select Yes and save the page, nothing is selected after page-reload. (there is neither Yes, No or Undecided with blue background)

Putting "use strict" should really be the default... It simply shows more hints and errors and this can be very useful while debugging. Using this in every JS file now revealed some data type mismatch too, when using !=== instead of !==. (see screenshots below) In trash.js I changed basically these lines: var gridInstance = $('.RockTabulator.tabulator'); var grid = RockTabulator.getGrid(gridInstance); and further below: // success if(result.success) { UIkit.notification(check + result.success, {timeout: 3000}); if( RockTabulator.getGrid(gridInstance).reload() ) { console.log('grid has reloaded!'); } else { console.log('grid has not reloaded!'); } // grid.reload(); } }, But as I said, since RT is not known inside that JS script, it can't call an unknown method getGrid...

Well, in the case of trash.js RT is clearly NOT defined and recognized. Try it out yourself. Consoles don't lie :-)

Also: if(!RockTabulator) { console.log('there is no RT here!'); } RT is not even instantiated / defined in trash.js, so even just hardcoding the tabulator with a DOM-selector won't help...

Yep: you should get used to use "use strict" in every JS file, then you would have found this error earlier: https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Strict_mode Now I see this is my console: Also, I see quite a few IDE warnings like these: panel.js: if(name != 'panel') return;

OK, I really gotta get going soon. I couldn't fix anything in that short period of time, but I noticed something strange: line 5 of trash.js: var grid = RockTabulator.getGrid(e.target); PHPStorm says "unresolved function or method getGrid" same goes for the next line: it doesn't recognize rowactions. Don't know if it helps...

*grumble*... yeah so now I restarted Laragon and used tabulator.test instead - seems to work now. Sheesh. Please do not use absolute paths/urls, but PW's $config->urls / ->paths instead.

And trying to open an endpoint link takes me to http://localhost/5d4dafe7929fd/?name=01_cats&type=debug which is rubbish, since I have this installation in a subdir: localhost/tabulator/

There's other funky stuff going on as well: When trying to access setup/rockfinder2/sandbox/?name=01_cats I get this: site/templates/.php ?

I give up for today, sorry.

OK, I did that, then tried to access the example file directly again, and whoops, get a 403 error. Updated to latest dev, and now even stranger stuff happens. I can't even get to the backend again - just get a 403 EVERYWHERE, incl. frontend. *sigh*

nope: I get "ProcessRockTabulator: No PHP file for rt12_rowactions found - please create it!"

Wow, the 2nd .sql loads really fast... wished I didn't waste time with the other one. But unfortunately, the "not writable" errors are still there.

Right, after clearing caches, I can now see your modules installed. Now on to the next challenge: Folder /tabulator/site/modules/RockTabulator/examples/ does not exist, Folder /tabulator/site/modules/RockTabulator/examples/ is not writable for PHP It exists, and the examples are there, but apart from the error messages I don't see any files in PW. I'm on Windows w/Laragon. Even trying to create a new file "rt14_test.php" didn't work: not writeable error again.

OK, finally the sql-import is done and I'm in the admin. But under setup/rocktabulator/ I just see "ProcessWire: Process does not exist: Module 'ProcessRockTabulator' is not present or listed as installable" and under modules it says "no modules found"

Wow... this should be fun! I removed the cache insert queries, but now it still says 7 hours (using HeidiSQL)... ?

Downloading now... but quickly looking at the code: Did you try to remove return false, and instead use event.preventDefault() after line 91 in _rowactions.js?

I'm not sure I get the full picture... Apart from analyses, are you doing anything else with this dataset in PW? Are those Excel fields also present as PW fields already? How do you plan to do this analyses in PW? Do users see this in the backend somewhere? Are you going to build something like a custom dashboard where every user sees their data? Or is it for management overviews? I don't know what this means. Depending on what exactly you need to do, you might even consider not using PW at all, i.e. use plain mySQL for data-storage / -update and analytics. PW has an excellent DB API you could use. I would definitely take a closer look at @bernhard's RockFinder / RockGrid modules, which dramatically optimizes queries in PW, and offers state-of-the art data listing.