dragan

Do you mean access them from an images-field on that page? In that case you'd change the image path to site/assets/files/page-id/ instead. But you'd still have to add the images to the field programmatically so that PW "sees" the new pics (via hook or Cron).

I wonder how all these years I never heard of John Frusciante's solo records... until a recent trip to Croatia, where the best cook in the village played some of his stuff... one of the most laid-back places I've ever been to at the Adriatic coast... And then there's this gem I discovered just 2 days ago:

Great news! At least one ray of sunshine on this rainy miserable day ?

@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"