bernhard

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 ?

I think it would make the communication easier because we wouldn't need to switch between languages within one single sentence. But I don't really care ?

That's exactly the point: The body field is attached to the blogitem template, but 0 pages have a populated body value (of 11 pages having template blogitem): So imho the number is showing how many fields on the given template are actually populated (befüllt).

Hi @dotnetic Maybe better "Befüllte Seiten"?

Is there any demo or live project running SnipWire yet? ?

The pw backend uses the old v4 icons from https://fontawesome.com/v4.7.0/icons/ You find instructions there on how to use them. But there are a lot newer libraries ?

Have you tried $this->_("translate me") ? (one underscore)

Hi @Alkrav sorry, I don't understand your question. You access the icon code via $page->your_icon_fieldname and display that icon as you like (eg "<i class='{$page->icon}'></i>")

Hi @sebr, happy to hear that ? Unfortunately, no. And I have no time to investigate. I can only share my experience: In my setups/modules I tend to use one single migrate() method now. Instead of having a migration for every version this approach just makes sure that after running migrate() you end up with the setup you want (fields, templates, pages). This is very easy using the RM migrate() method: $rm->migrate([ 'fields' => [ 'foo' => ['type' => 'text'], ], 'templates' => [ 'foo' => ['fields' => 'foo'], ], ]); Lets say in the next version I need a new field "bar", I'd just add it to that migration: $rm->migrate([ 'fields' => [ 'foo' => ['type' => 'text', 'label' => 'Foo Label'], 'bar' => ['type' => 'text', 'label' => 'Bar Label'], ], 'templates' => [ 'foo' => ['fields' => 'foo', 'bar'], ], ]); This makes it really easy to grasp the setup, because you have everything in one place and you don't need to go through every migration and try to understand the whole picture. The example above with the "old" approach would be: $rm->setFieldData('foo', ['label' => 'Foo Label']); $rm->createField('bar', ['label' => 'Bar Label']); $rm->addFieldToTemplate('bar', 'foo'); Not to forget that with the new approach you can diff your changes: Of course this comes with the drawback of a little less control and it can get tricky when multiple modules to migrations and one depends on the other. But then you can still split migrations up or do necessary changes upfront. Also removing things needs some extra lines of code, but still very easy ones: $rm->deleteField('bar'); $rm->migrate([ 'fields' => [ 'foo' => ['type' => 'text', 'label' => 'Foo Label'], ], 'templates' => [ 'foo' => ['fields' => 'foo'], ], ]); On uninstall I just do all the cleanup and that's usually as easy as deleting all templates and fields (because all pages get deleted automatically). I've never ever needed to run a downgrade method. I usually have a cleanup migration that just removes fields or templates that I created during dev and maybe even pushed to the live server and then I change something and dont need those fields any more (like the "bar" field above). RM is still not perfect. I had a chat with horst and I'd like to have logging and test-run capability, but for now this is what we have and it is saving me a ton of time and headache already and I can really not understand how anybody can work with ProcessWire without RM ?

Well, then I think you have two options: Build a custom user-area on the frontend (like a user-backend on the pw-frontend) Use the PW backend and customize it as much as possible Both have pro's and con's depending on the exact situation.

https://www.google.com/search?q=site:processwire.com+change+default+language

What security concerns do you have? How many users are we talking about? Aesthetic reasons: You can totally individualize your admin! Looks like you are using uikit for your frontend, so that would be quite simple. I've built a custom admin theme that looks like this: It's based on one main color that can be changed to whatever you want (as long as it contrasts to white). It's not public (yet?), but if you're interested you could pm me.

Thx for this one @adrian and @kixe that really saved me today ? This is my final version: public function init() { $this->addHookAfter("ProcessPageEdit::buildForm", $this, "addGUI"); $this->addHookAfter("ProcessPageEdit::buildFormContent", $this, "addGUI"); } public function addGUI(HookEvent $event) { $tabid = 'my-tab'; $form = $event->return; $page = $event->process->getPage(); if($page->template != 'my_page_template') return; // add new tab after content tab if($event->method == 'buildFormContent') { $event->process->addTab($tabid, __('My Tab!')); return; } // add fields inside the tab $tab = new InputfieldWrapper(); $tab->id = $tabid; $tab->add([ 'type' => 'markup', 'label' => 'foo', 'value' => 'foo', ]); $tab->add([ 'type' => 'markup', 'label' => 'bar', 'value' => 'bar', ]); $form->prepend($tab); }

Another one: installieren --> installiert Thx ?

Depending on the situation (how many subscribers etc) this could be really simple to implement on your own: A form that subscribes an email to the current page (using $page->meta('subscribers') for example) A hook that sends an email on every publish of a child of the subscribed page (using WireMail) A magic link in every email to unsubscribe (eg unsubscribe section or unsubscribe all) It get's more complicated of course if you got a larger number of subscribers or you need to deal with legal stuff (opt-in, mail confirmation links etc) - but sometimes simple solutions are totally fine (eg if you only have a handful of trusted users)...

Hi @cb2004 sure, easy fix - but untested! Let me know if that works ? https://github.com/BernhardBaumrock/RockAwesome/commit/61743d343c328f37f8ef5e4e49b25a5ea4c5ade8

RockFinder3 has a performant and versatile SQL groupby feature: https://github.com/baumrock/RockFinder3/tree/40da7c5f087d87bc33d883add5b78cf7c546bacd#predefined-methods

He's on fire ??? Really not a big thing, but how would one remove this item? ? Business hours can be a pain... Have you thought about using a library? eg https://github.com/spatie/opening-hours Maybe you have an idea for a good UI regarding exceptions (like holidays etc)? Very nice UI btw! ?

My approach from today: $wire->addHookProperty("Page::myFooLabel", function($event) { $page = $event->object; if($page->template != 'foo-page') return; $event->return = $page->title . " (foo label)"; } Then just set the label field to "myFooLabel" and enjoy. This also has the benefit of having the dynamic label always available easily via $page->myFooLabel

v0.0.19 adds support for RepeaterFields @zoeck $rm->migrate([ 'fields' => [ 'my_repeater_field' => [ 'type' => 'repeater', 'label' => 'This is my great repeater field', 'repeaterFields' => ['title', 'body', 'images'], ], ], ]);

Hi @Nicole Bardales I don't have a solution for you yet, but a recommendation that might help: Install TracyDebugger and you'll get a better output of your error and also some great tools for debugging your scenario. For example you can add bd($var) calls in your code and get a nice visual dump of your variable and can then track the issue down. It is a great tool for learning PW and PHP in general because it makes a lot of things visible that are usually hidden somewhare in the memory ? Hope that helps a little ?

Hi @spercy16 welcome to the forum! Could you please tell us a little bit more what you already tried (beside using google)? Also it would be great to hear a little about your experience with ProcessWire and WebDev in general so that we can provide better answers for you.