bernhard

Ok I get your point and usecase.

I know it feels complicated in the beginning. I've been there 4 years ago when Lostkobrakai was talking about that mystical thing called Migrations. I've put a lot of effort into my module to make simple things simple without the technical overhead of needing custom classes for each migration like in the other module (that has other benefits of course). https://processwire.com/talk/topic/21212-rockmigrations-easy-migrations-from-devstaging-to-live-server/?do=findComment&comment=208165 $rm->migrate([ 'fields' => [ 'foo' => [ 'type' => 'text', 'label' => 'My foo field', ], 'bar' => [ 'type' => 'text', 'label' => 'My bar field', ], ], 'templates' => [ 'mybuilderblock' => [ 'tags' => 'MyBuilder', 'fields' => ['title', 'foo', 'bar'], ], ], ]); It really can't get simpler than that! And I think that is something that can be done by anybody - even non-coders. TracyDebugger does even have a "field code" panel where you get those code snippets. So you can create fields and copy the code over. Once familiar with the field properties (they are always the same) you get a LOT more efficient with code setup. Add a new field? copy the 3 lines of "bar", rename the field, done. Make those 3 fields have all 33% width? Use multicursor in your IDE and all fields are 33%. Compare that to field import/export or other setups... Edit field 1, set field width, save. Edit field 2, set field width, save. Edit field 3, set field width, save. Don't like the result? Edit field 1........... you get it ?

Have you had a look at RockMigrations? You get the best of both your worlds: Easy migrations + version control...

I'm using ProcessWire all the time for Backend-only applications. Sometimes I also feel like I'm using it in a "wrong" way... But sometimes it seems that there are more people using PW for database applications. I think it is a great tool for such scenarios - I have to admit though that I did not try any others. What's really missing is a way to present tabular lists. That's why I created RockGrid/RockTabulator/RockFinder. RockFinder3 is a great product, while RockGrid/RockTabulator is better than nothing but I'm working on a better solution ? I don't get your problem though... What's wrong with a list like this? id | forename | surname | address | name 1 | john | doe | exroad123 | 1 2 | john | doe | exroad234 | 2 3 | maria | müller | musterweg | 3 I tend to use the title field for a representation of the page that can be used easily on page lists etc: id | title | forename | surname | address | name 1 | john doe (exroad123) | john | doe | exroad123 | 1 2 | john doe (exroad234) | john | doe | exroad234 | 2 3 | maria müller (musterweg) | maria | müller | musterweg | 3 That's a simple saveReady hook. I'd recommend using custom page classes a lot for such setups. It keeps the code clean and a lot easier to maintain. You'll also get the benefit of code completion in your IDE and your hooks will get a lot cleaner, easier and better maintainable as well: // in site/init.php or an autoload module $contact = new Contact(); $contact->init(); // in site/classes/Contact.php <?php namespace ProcessWire; class Contact extends Page { public function init() { $this->addHookAfter("Pages::saveReady", $this, "setTitle"); } /** * Get page title based on other fields * @return string */ public function getTitle() { return $this->forename." ".$this->surname." ({$this->address})"; } public function setTitle(HookEvent $event) { $page = $event->arguments(0); if(!$page instanceof self) return; $title = $page->getTitle(); $exists = $event->pages->get([ 'template' => $page->template, 'title' => $title, 'id!=' => $page->id, ]); if($exists->id) { // page exists, show error message and do whatever is necessary } else { $page->title = $title; } } } Code completion will help you a LOT when the project grows... Combine that with RockMigrations and you feel like you got superpowers. At least I do ?

Another quick and easy one ? Place this in /site/templates/admin.php before the require(...) statement: $this->warning('Attention: We have planned maintenance starting 2021/02/11 from 10:00 AM - log out before that date to prevent data loss.');

Found one that was new to me: https://plotly.com/javascript/ based on D3 and seems to have a LOT of options/possibilities! ? Anybody any experience with it?

Really brilliant! Thx @Robin S and @adrian ?

Thx - no answers seems that I'm not missing anything obvious here ? If you like, give this request a thumbs up: https://github.com/processwire/processwire-requests/issues/386

I thought so as well for quite some time, but I also had several problems related to AOS and wasted too much time for debugging just to find out, that AOS was the reason... That's why I don't use it any more and I was surprised - I don't really miss it ? It's nice in many ways, but it's not essential imho and I personally don't want to take the risk of getting too used to a module that does not seem to be maintained any more and potentially brings in too many problems. No AOS bashing here - just trying to support his concern ? I'd much more prefer to get some of AOS features into the core...

What about this? ? if(!$user->isLoggedin() AND $page->template == 'sometemplate' AND $input->get('code', 'string') == $page->page_pass) { $page->removeStatus('unpublished'); }

For advanced needs there is a module from @Robin S : https://processwire.com/talk/topic/21153-access-by-query-string/ But if you need something really quick and simple, just put that in your init.php: if($input->get('code', 'string') === 'YOURSECRET') { // remove the unpublished state in memory (non-persistant) $pages->get('/yourpage')->removeStatus('unpublished'); } This makes /yourpage accessible via /yourpage/?code=YOURSECRET ? PS: I had this need today to show a page to a user that has no login and to make sure that the page is also excluded from search results (that's why just hiding the page would not have been enough).

Just wondering... A client called me yesterday: "Bernhard, I deleted a project, can you restore that?" It was not that simple, because that project had related pages that have also been trashed. Restoring those pages would have been a lot easier if the trash in the page tree showed the trashed pages sorted by time of deletion. What do you think? How to you find such pages quickly? Am I missing anything? I've used a custom $pages->find() in tracy console to get what I want...

That moment, when you read your mails early in the morning and ask yourself: "What deeper hook is adrian talking about?" ?

Sounds like you are a little afraid of hooks ? My post here might help: https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/?do=findComment&comment=158164 I've even added a new comment how to find things out in the IDE (without having to dump the results using tracy)

It's only much more efficient as long as it only finds IDs and that's just using findIDs... as soon as I add a column of data the new findRaw is much quicker! Actually finding 1000 pages with just the ID column taking almost 2 seconds seems quite long... But I don't have time to investigate further at the moment.

Haha sorry, I got so used to ALT+ENTER and always reset the console that I totally forgot about that "feature" ? Thx for the reminder!

For simple queries we now have findRaw() in the core! Seems like joining columns could be improved in terms of performance... @adrian other than in your example I had to fire separate d() calls to get separate execution times and mem consumptions?! Am I missing anything?

Hi Ryan, thx for the update! Is there any reason why the label field is required? I find that really annoying - I'm leaving that blank most of the time while developing, because I see the name of the field instantly and change/fill the label only if the setup turns out to be working properly. Otherwise removing fields, renaming fields etc. is more work than necessary, because one always has to fill/rename one additional field that does not add any benefit. Would be great to revert this back to optional. I like the new interface, though. But it would be better IMHO to show name | type | label (optional) PS: I saw that the page name fills automatically based on the label - that might be nice for all english speakers, but most of the others I guess will usually have different labels and field names, because the label is in their language while the field name is english...

Good writeup, thx @gmclelland ? Exactly what I thought, when I read your concept. I think the best solution would be to have the page editor work only on the frontend. Then editors have the final layout instantly visible on the right half of the screen and when they click on a block, they can edit that block in a sidebar on the left. If the block had a nested block, they could simply click on that block, which would open a new sidebar at the same position on the screen (left side), overlapping the old sidebar, then closing it. So the editor would be in the nested block and if he/she wanted to go back to the parent block, he/she could click either on "parent" (maybe having breadcrumbs, as you mentioned) or choose the block to edit from the right side of the screen (live preview). Well, that's exactly the concept @kongondo has shown in his video ?

Ah - maybe my devtools stylesheet is still active... I'll report back! Yeah, good idea for such testing scenarios ?

thx @adrian this is strange, because I just tested and it seems to work in the console/bardump:

I think it might be helpful to have a thread dedicated to css fiexes/improvements? Could the bd() dump at the bottom be single line only with a css text-overflow ellipsis? https://developer.mozilla.org/de/docs/Web/CSS/text-overflow This is what I tried as a quickfix in devtools on the <a> tag: element.style { text-overflow: ellipsis; white-space: nowrap; display: block !important; width: 90%; overflow: hidden; }

Yep, that would be great! And it would also be great if it was possible to input 1,23 (using comma), because we have , (comma) and not . (dot) on the numpad:

The PW core comes with many great classes such as WireData, WireArray and so on. Sometimes I'm developing stuff without a running PW instance and I'd love to have the great PW api available there as well. I've mentioned that in the PW Roadmap 2021 thread and Ryan stated: https://processwire.com/talk/topic/24897-weekly-update-– 8-january-2021/?do=findComment&comment=209891 That sounded interesting, so I've tried how that works and created a repo for quick and easy testing so that everybody can try what works and share their findings so that everybody can learn. https://github.com/baumrock/PwStandalone PwStandalone The ProcessWire core has many great classes such as WireData, WireArray, WireRandom etc.; Many of them can be used without a running PW installation! This repo helps testing those features and hopefully will motivate others to share their findings (as PRs). It's as simple as creating a new file in the examples folder! I'd appreciate any help regarding the examples throwing an error! PRs for other examples that you've tried very welcome!

d() is the dumping feature of Tracy Debugger ? Use it in the tracy console code panel and you'll be a lot faster with such quick php snippet tests/creations ?