bernhard

I'm using frontend editing all the time. Suddenly on my new project when I tried to copy and paste several regular text-field contents: I ended up with markup in my fields: So I always need to hit the edit icon to edit it in the modal which shows the backend inputfield and there I can safely copy&paste like this: Any ideas why this would happen? I'm not sure why I didn't experience this behaviour so far. Maybe it's an update of something?

Glad you got a working solution, but what you said is not 100% correct ? I used $page->template != 'something' and this will work. But it will only work if you use the "not equal" (!=) operator. It will NOT work, if you use the "not identical" (!==) operator! Check this out: So if you use the two letter comparison (== or !=) then PHP will try to convert your $page->template into a string and ProcessWire will be smart enough to use the template's name. So you'll end with a string == string comparison and you should get the desired result. If you use a three letter comparison (=== or !==) then PHP will not convert $page->template and object === string will always be FALSE and object !== string will always be TRUE. Hope that makes sense ?

correct ?

There seems to be a module that does what you need: https://processwire.com/modules/restrict-tab-view/ (at least for the tabs! I haven't used it though). But you can do both quite easily with two hooks in /site/ready.php - unfortunately you can't do everything in one hook because you need to hook "before" and "after" the buildForm(Content): <?php // hook to make the title field non-editable $wire->addHookAfter("ProcessPageEdit::buildFormContent", function ($event) { // get the page being edited $page = $event->process->getPage(); // check if the page has the desired template if ($page->template != 'your-template') return; // check if the user has the desired role if (!$this->wire->user->hasRole('admin')) return; // get the form that was built in buildFormContent() method $form = $event->return; // make the title field non-editable $f = $form->get('title'); $f->collapsed = Inputfield::collapsedNoLocked; }); // hook hide the settings tab $wire->addHookBefore("ProcessPageEdit::buildForm", function ($event) { // get the page being edited $page = $event->process->getPage(); // check if the page has the desired template if ($page->template != 'your-template') return; // check if the user has the desired role if (!$this->wire->user->hasRole('admin')) return; // set noSettings property dynamically $page->template->noSettings = 1; });

Hi @olafgleba thx for sharing and congrats for the great result ?? Not sure if I understand that correctly, but wanted to add that you might not need an additional field here. Not saying an additional field is bad, though ? You could either access the user that created the page via $page->createdUser or, if you need a different logic you could use $page->meta('youruser', 'yourvalue') instead of adding a field to that page and then use that for storage. Have you thought of using url hooks or url segments to show your content with custom logic at a custom/different location than the original url? You might save you from the hassle of keeping everything in sync then.

With RockPageBuilder this would look like this: You can easily create new blocks by clicking on the plus after the last block and every block consists of one PHP file for the business logic (if needed), one PHP/LATTE file for the output markup and optionally one .less file for the stylings: If you do it smart then you can even reuse these blocks in other projects just by copy and pasting these files ? Compared to RepeaterMatrix which would also be a possible solution RockPageBuilder comes with great integration and a complete UI for frontend editing: So instead of using $block->headline to output the headline of the block you simply use $block->headline() and your headline will be frontend editable!! For non-text fields you can double click anywhere and the editing interface will be loaded in a modal. ? I've not done a single website without that module for a very long time ? It will be 49€ for a single site for early birds. I'm working on the docs and on the webshop at the moment, but there are already several people from the forum using it for real projects, so if you are interested just write me a PM or signup to rock monthly to get notified when sales start ?? https://www.baumrock.com/rock-monthly/

I thought that repeater pages have their own template, sorry. If that's not the case then just modify my hook to check the page's parents: Here the $page is a repeater item. You can inspect its parents like shown in line 1 and you can add something like shown in line 2 into your hook to only fire that hook that overrides the title if the parents have your repeater parent page. If not, then early exit of that hook. <?php $wire->addHookProperty("Page::title", function ($event) { $page = $event->object; if(!$page->parents->has("name=for-field-157") return; $event->return = $event->object->headline; });

Ah, sorry - that's what I already showed in my previous post! Just find out the template of your repeater items and use the hook that I posted.

If you compare both approaches it would be interesting if you share your findings. https://processwire.com/blog/posts/debugging-tools-built-in/ (Debug::timer) might be helpful and memory usage could also be interesting.

Note that this does NOT help with scalability issues. Quite the contrary. It will keep two page fields in sync but it will store the data twice. So if you have lots of pages, you'll make your issues even worse.

I'm thinking of removing ALFRED from RockFrontend. Is anybody at all using it in any projects??

I guess the module uses something like $page->get('title|id') for the labels and since your page has no title field it falls back to the id. You can easily overwrite the "title" property of your page via hook! In this example I overwrite it for the "repeater_rpb_textgrid_items" template and set it to display the field "rpb_textgrid_headline" instead of "title": <?php $wire->addHookProperty("Page(template=repeater_rpb_textgrid_items)::title", function ($event) { $event->return = $event->object->rpb_textgrid_headline; });

How many documents? How many users? If you only have a limited number then a simple page reference field would be all you need. Just add a field "readby" to your documents page and add users to that field via API. You just need to make sure that you don't have too many pages stored in the page reference field. So if you have many documents but just a few users add the page field to documents. If you have many users but just a few documents add the page field to the user template and add read documents to the field. If you have many documents and many users go with the custom table solution that I showed here:

I'm quite sure you did, but just in case: Did you check if there is a plugin that can fix your issue?

You have to read carefully. What I showed was the syntax for saveCustomField() method. You now posted the one for addCustomFieldToPageEditForm() - that are two different things. saveCustomField hooks into Pages::saveReady, therefore the $page is available as the very first argument of the HookEvent: $event->arguments(0) or $event->arguments('page') addCustomFieldToPageEditForm on the other hand hooks into ProcessPageEdit::buildForm, therefore the edited $page is available as $event->object->getPage() Your solution is fine as well, but it will only work for situations where the page id is available as a get parameter. So I'd recommend you read again my post/video about hooks here: https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/#comment-158164

Ah and I'm not sure if that is a good idea. wire('page') is the current PW page. Did you check if that is really the correct page and not the page with id 10 that is responsible for rendering the page edit form?? I'd better get the edited page from the HookEvent: $page = $event->arguments(0);

I think you are just missing this after $field->description = ... $page = $event->object->getPage(); $field->value = $page->meta('custom_text_field'); ... and maybe some sanitisation in saveCustomField() ?

Adding custom PHP code to any page in the backend is extremely easy as well (if you know how) ? <?phhp // in site/ready.php $wire->addHookAfter("ProcessPageEdit::buildForm", function ($event) { $form = $event->return; $page = $event->object->getPage(); if ($page->template != 'home') return; $existingField = $form->get('title'); $out = "Show 5 random pages:"; $pages = $this->wire->pages->find("limit=5, template=basic-page, sort=random"); foreach ($pages as $p) { $out .= "<div><a href={$p->editUrl}>{$p->title}</a></div>"; } $newField = [ 'type' => 'markup', 'label' => 'foo', 'icon' => 'check', 'value' => $out, ]; $form->insertAfter($newField, $existingField); });

I've just tested this: $home->of(false); $home->rockfrontend_favicon->add(__DIR__ . "/Test$$$.png"); $home->save(); bd($home->rockfrontend_favicon->uploadName()); Which resulted in this: So that confirms that uploadName() does not work for API added files.

I've added your example to the mentioned issue: https://github.com/processwire/processwire-requests/issues/56#issuecomment-1704363956

How did you upload the file via api? Can you give a quick example to reproduce the issue? If you do that and post it to this issue and mention Ryan I guess chances are high that he will fix this quickly. At least I suggested the uploadName feature on Feb 16 and he implemented it on Feb 17 ? Maybe he just didn't think of API uploads.

New video about DDEV is out ?

We are live and have a very special guest in the video ???

Hi @ryangorley and welcome to ProcessWire and the forum. Thx for your introduction, this sounds impressive and it sounds like you can have a lot of fun with PW and maybe even help us to make PW more popular one day as PW really lacks good marketing in my opinion, but that's another story ? Back to your questions and back to the mentioned modules RockMigrations and RockFrontend, which I created. This is definitely a topic for me and I've talked to many other PW devs and it's a topic for many. I don't know what to do about that, but it's a fact that PW is very unpopular and infamous and it's also a problem for many that it's basically developed by one single guy somewhere in the world and nobody really knows what happens if something happens to Ryan. Also I often hear from clients that with wordpress they just use google or youtube and instantly find a solution for their problems. If that is good or bad is another story (I'm talking about the plugin ecosystem and the idea that anybody can build a website without any knowledge). But in my experience this is a very common opinion or perception among clients when they think about websites. "WordPress is so easy to use" is another one. On one hand I totally disagree, because the PW backend is usually so much cleaner than WordPress and my clients usually can manage their websites on their own instantly without any education, but on the other hand every website that we create with PW is an individually developed piece of software and works like the developer thought it should work. There are almost no restrictions and no standards, which most of us here love because we can develop everything the way we want and we think it's best, but on the other hand everybody knows how hard it can be to take over a PW website that someone else developed... Maybe it's a little like Windows vs. Linux - you can customise Linux a lot more, you have a lot more options, you have a lot more security, maybe a lot more power and possibilities. But it's more work. Windows is easier to understand. It has a solution for everything that you just install (like WP with its Plugins). Is it hard to convince clients to use Linux instead of Windows? I guess nobody here knows that better than you ? RockMigrations TracyDebugger RockFrontend RockMigrations is #1 because it installs #2 and #3 for me ? Actually the very first thing I install is RockShell, but that might be very opinionated and advanced. RockMigrations is also advanced whereas Tracy and RockFrontend are a no-brainer in my opinion. TracyDebugger A must-have for me in every project. It made me understand PW and PHP a whole lot better. It makes me a lot faster in my everyday work. It's an invaluable tool and I can't thank Adrian enough for developing it and sharing it with us. Pssst: https://github.com/sponsors/adrianbj The beauty of PW is that you don't need all this if you don't want to! Just use direct output for your first project and just put <?= $page->something ?> in your template files and enjoy the magic. Once you are familiar with the basics and you found out about the limitations of direct output have a look at the delayed output approach. I've been using markup regions for a while, but I don't like them any more. I think they are confusing and I think they should be removed from the default profile as they are adding another layer of complexity that should not be there at the very first impression that someone gets when discovering PW. Usually PW does a really good job in hiding complexity. It is really easy to use from the very beginning (both for the developer and the clients) but it provides all the power once you get more familiar and your projects get more complex. Markup regions violate this concept and your statement seems to support that impression. RockFrontend Whatever output approach you choose RockFrontend can make your development life a lot easier. It does not dictate you anything and there is not really anything you need to learn unless you want to. You can use RockFrontend solely for it's invaluable live reload feature. Just enable it in your config and you get instant reloads whenever you change a file. This can even be combined with TracyDebugger: I'm often using /site/ready.php to quickly test something and I'm using bd($foo) to dump the result to the tracy debug bar. Whenever I save the file I instantly get the result in my tracy bar without moving my hands away from the keyboard. Productivity ? If you want, you can then discover all the other great options that RockFrontend provides. LATTE/TWIG for example which is really just "echo $rockfrontend->render(your/file.latte);" or helpers for asset handling (you get automatic cache busting timestamps for example). I've created a video about all that one year ago: But again: If you only want to use the live reload feature - only use the live reload feature and nothing else ? RockMigrations This is a gamechanger. For me and in the meantime for several others. But it is totally worthless for others. It's an advanced module, but this does not mean that it is hard to use. Quite the contrary is true. Once you get the concepts it is really easy to use and it makes you a lot more productive and a lot more professional. It's like driving a car vs. going by foot. Learning all the rules and signs is not that easy. It takes some effort. But driving the car itself is not hard. It's in fact very easy. Steer, gas, break. That's it. When using RockMigrations you simply do in code whatever you usually do via mouse clicks. $rm->createField(...); $rm->addFieldToTemplate(..., ...); That's it. If you prefer to do that manually - do it manually. Carrying a bike from A to B might be easier by foot than by car. You might even ride the bike which makes it even easier if the road goes downhill. But what if it goes uphill? A car might be easier. What if you need to carry two bikes or three? A car might be easier. What if you want to carry the bike 200km? A car might be easier and a lot faster. So if you want to create reusable components (like modules) RockMigrations can be invaluable for you. If you want to develop projects in a team of multiple developers RM can be invaluable for you. If you want to deploy your project to several places (like DEV/STAGING/PRODUCTION) RM can be invaluable for you. Video time again ? Have fun with ProcessWire! PS: As @elabx mentioned DDEV is a great tool as well! I've done a talk about it lately and the video about it will be on my channel next week, so if that's interesting for anybody just subscribe to my channel or to the Rock-Monthly newsletter: https://www.baumrock.com/rock-monthly/