bernhard

Yeah you can edit entries of course, but with a link that opens a panel or a new tab. Nothing that is great for bulk editing of many entries at once 🙂

Thx for the kudos @Mikie but I think my modules will not make @fruid's clients happy. My modules are solving the problem of finding and/or displaying data, but are not doing anything in regards of bulk-editing data quickly 🙂

Not sure, but you could create a test site using the blank or default site profile, then create 10k, 100k, ... pages and see if that has any impact on the page save timings.

Some background info: https://github.com/processwire/processwire-issues/issues/579 Are you sure that the 10s delay is coming from the huge amount of folders?

Thx! Good to know that. This should be quite an easy fix (something like changing getQuery() to getDebugQuery())...

I think that should be a lot easier. You can setup any vhost you want on your server to access your website, eg website.com, website2.com, or as subdomain admin.example.com. So you setup 2 vhosts, one that points to the root dir with the folder containing your pw installation, so that you can access the frontend (example.com/app) and one that points directly to the app folder (eg admin.example.com) In admin.php you add some PHP to check for $config->httpHost and block access to the admin if the request comes from example.com or www.example.com. In ready.php you add some PHP that redirects requests coming from admin.example.com to admin.example.com/yourpwadminurl --> if anybody visits admin.example.com he/she will be redirected to admin.example.com/yourpwadmin --> users visiting example.com/app/yourpwadmin will be redirected to example.com/app (or blocked via 404, as you like)

Quick idea, not well thought through: You could also create a custom DB table on which the client can work on and you write a script that pulls data from that table and populates pages via API (or synchronizes both).

Hi @David Karich, happy to hear that 🙂 Did you do a transition from RF2 to RF3 or are you using it in parallel? Would you mind sharing some details about how/why you are using RF with us? 🙂

This one is actually important because it is misleading. @dotnetic could you please change that to "Aktion wird beim Speichern angewendet"?

What do you guys think of changing that to Vertikal spiegeln Horizontal spiegeln Beides spiegeln 90° drehen (rechts) 90° drehen (links) 180° drehen S&W Sepia Actually I don't understand why we have the options for 270° rotation at all? -270 = +90, so why does it show up??

Hahaha, read the post to the end before answering 😄

Hi @fruid, I understand your concerns. The db structure can look quite complex, especially if you are used to working with db tables and SQL select ... from ... etc; Teppo explained the reason for this structure. The great thing about this structure is that you get an abstraction layer that makes all the PW awesomeness possible. It transforms all the custom fields and data in the database into PHP page objects that can be used for easy and effortless markup generation. I'm talking about the great pw api 🙂 echo $page->title; echo $page->headline; echo $page->image->size(200,200)->url; Display all that in multiple languages? Same code 😎 I think that's really genius! Are there downsides of this approach? Yes, as always. For example it is not easy for PW to do a "SELECT * FROM table_xy" to get a list of thousands of rows of data. That's because the magic of transforming the complex db structure into an easy to understand and use API has some costs. It needs to load all rows of data into memory and therefore this get's slow when working with lots of data. PW handles this by applying pagination wherever possible, so that it only loads chunks of data and stays fast. But still there might be situations where you simply need a good old "SELECT * FROM ..." and "foreach($pages as $page) $rows[] = [$page->title, $page->headline, ...]" is no option. That was quite a long introduction and explanation why I built RockFinder3 😄 So at least the PULL part of your request is already doable 🙂 What about the PUSH part (meaning updating data in the DB, doing "UPDATE ... , INSERT INTO ...")? First, you can still use native SQL commands on PW, it's quite easy: $result = $this->database->query("SELECT * FROM pages LIMIT 5"); var_dump($result->fetchAll(\PDO::FETCH_OBJ)); The problem is, that updating data can get quite complex because you need to update several tables, several fields, several languages... That's why such operations should really be done via API. That's of course a totally different approach if you are used to working with SQL commands, but it is the best option in 99,5% of the cases. There's a topic about that where I showed my findings: For the remaining 0,5%: You see, it can be quite easy. Is it a good idea? 99,5% no, because you don't get all the security features of PW that ensure that data is sanitized before storage etc. And you don't get the power of hooks. Updating pages via API will still trigger saveReady() and saved() hooks while direct SQL updates will not. Hope that helps 🙂

Thx for the report. Can you please give us some more details, I don't really understand what you mean 🙂

Hi @MarkE If you find any php less parsing library that supports it I'm happy to add support. it might be possible to add it.

Just wanted to link a solution for people that are in a hurry 😄