dragan

I mean this: note the "active" checkboxes. OK, now I know a bit better what you mean. These pages are not created "manually" in the admin, but from a page-reference field that has the option "allow to create new pages?" in the field settings. If that is indeed the case, I wouldn't know what the expected / default behavior would be. Only create the page in the default language? (which seems to be the case). I don't know if that is configurable. I don't have time right now to investigate - maybe you'd have to use a hook to automatically activate all languages when creating a new page like that.

Well, there are two things to watch out for: Is the page activated in the alt. language? How is the title-field configured in the alt. lang. page version? At field-level, you can define the behaviour of what's shown, in the details-tab: If you use the option shown above, you still have to make sure the alt. lang. page version is activated.

Do you have an ___executeRefresh() method? There's plenty of infos in this old thread:

Which "main menu"? In your frontend-template, or in the backend?

Yep, that's certainly worth a try. See this announcement from @ryan https://processwire.com/blog/posts/using-innodb-with-processwire/ tl;dr: Row locking versus table locking (Inno vs. ISAM)

I won't ??? I just realized the "view" link in the RF Tester (zooming glass icon) seems to be hard-coded: it's assuming my PW backend is "admin". This should probably be defined dynamically instead (or at least configurable). Also, I noticed the div.paginationPageSize is always showing "undefined" o_O

What do you mean with "better standard"? You can move your custom process module within 2 seconds. That's not really too cumbersome, isn't it? In this example, dashboard + forms are top-level links in the admin, not under "setup". The "default standard" prevents breaking the top-level admin links to have too many items and therefore maybe breaking the navigation (visually, i.e. two or three rows instead of just one).

@Lutz True. But maybe I'll have another setup where I need to query pages that live under different parents, and (theoretically) also could have identical page-names. @bernhard Now that sounds both easy and awesome (plus "safe", in the sense that a page ID is always unique, while page-names aren't - unless they are children under the same parent page). I've been playing a bit more with RF... pure awesomeness and fun. Together with Lazy Cron, Tabulator.js and RF, a small test-setup runs incredibly fast. (Lazy Cron to store the RF-output - JSON - once a day). Makes me almost sad I currently don't have a real use-case / client-project to use all this...

Where? In the frontend or backend? If you're doing forms in the frontend, you have to write your own validation logic. Or do you refer to field dependencies in the backend ("required only if...") ?

Sabre seems to be the market leader. Other hotel sites built with PW also use it. There's also https://hotelnetsolutions.de/cbooking-onepagebooking/, https://www.simplebooking.travel/de/ or https://www.dirs21.de/direktbuchung/

That was an issue until v. 3.0.85, but apparently was fixed in 3.0.86. What PW version are you running?

Two small questions (and I guess I know the answers already): a) I can't get any RF output (arrays, objects) to play nice with PW's pagination / renderPager(). I guess pagination expects a PageArray, not just any kind of array. I know RF was never meant to be used in the frontend, but I tried anyway (and of course, I know building my own pagination with something like Tabulator is quite easy). I just wanted to compare an existing page (how much speed I would gain using RF instead of native PF find). b) I tried queries like $finder = new \ProcessWire\RockFinder('parent=1041, include=all, template=project, sort=-year', ['title', 'year', 'modified', 'url']); url is not recognized. I guess because a PW page URL is not stored inside the DB as-is, but is created when calling the $page->url() method. Am I correct? (PW has to assemble parents(s), page-names etc.)

This happens when I run setup/rockfindertester/, but Tracy is enabled. When I use RF code inside Tracy console in Chrome, everything's fine.

I am getting ERR_RESPONSE_HEADERS_TOO_BIG in Chrome with the RockFinder Tester. After googling, I tried to add this line at the top: header_remove('Set-Cookie'); which doesn't change anything. Did you ever encounter this as well? Problem is, this even happens for really small datasets like limit=10 :-| In Firefox there are no such problems, even with huge datasets.

hmm, the iframe looks in my PW install like this: <iframe class="pw-panel-content" src="../setup/manual/?modal=panel&amp;pw_panel=1"></iframe> If you work with JS, you could also check for body class "modal".

The easiest is to install Tracy Debugger and use the user-switcher panel

As an alternative, you could store it on the file system, outside the web root. Perhaps like user-id_token.txt or similar.

You could take a look at https://modules.processwire.com/modules/access-by-query-string/. Maybe it'll do exactly what you need, or you could take it as a starting point and tweak it to your needs.

Is there a way to index all pages without editing each page and save again? i.e. if I install the search engine in an existing site. Can I just do: $modules->get('SearchEngine')->indexPages() ?

@Edison Thanks for your feedback. I have googled far and long, and have also looked in the module code. I can append to existing sheets easily, and reading from them too. I don't know why Ryan didn't implement $range as a parameter, but only $fromRowNum (int). Probably because in most cases, that's all you need. Could just as well be an oddity with the original Google API code... *shrugh*

Can you upgrade to the latest Lister v1.1.2 β ?

For the first time ever, I tried to play around with PW's new Google Client API module. Installation was successful. The basic example with Sheets API (reading content from a sheet) went well. However, writing to a sheet throws an error: // Google_Service_Exception #400 { "error": { "code": 400, "message": "Requested writing within range [Tabellenblatt1!A1:A2], but tried writing to column [B]", "errors": [ { "message": "Requested writing within range [Tabellenblatt1!A1:A2], but tried writing to column [B]", "domain": "global", "reason": "badRequest" } ], "status": "INVALID_ARGUMENT" } } I have used Ryan's example. The sheet gets created, but nothing else happens. Does anyone know what this error message means in plain English?

To me, BEM + principles of Atomic Design + SASS is the way to go. I was quickly looking at that Tailwind page "extracting components". You can do exactly that with mixins. It's already there as a fundamental cornerstone of SASS. Why re-invent the wheel? And the M in BEM (modifier) gives you the flexibility you need without adding a truckload of utility classes or duplicating code. Also, if you want to just have a small, but very flexible layout (grid) SASS lib, I can highly recommend https://www.oddbird.net/susy/ Having said all that - I really really love the way you can use scoped CSS (SASS) inside Vue components. No chance of naming collisions, and you don't even need BEM anymore: Each CSS-rule lives in its own scope. What's actually finally rendered in the build will be named something else, but that doesn't matter. It just works. A great relief and time-saver.

??? ???

I guess this should be possible with a good old hook, too.