bernhard

Browser cache? Logged in vs. not logged in? Copy the markup from "else" (the one that shows up) to "if" and see if that makes a difference. Maybe you have an error with some closing tag or quotes that the browsers handle differently...

That <p> tags come from ckeditor: https://processwire.com/talk/topic/10999-ckeditor-remove-wrapping-from-in-source-code/ The easiest solution would be to change your code to this: <div style="color: white;"> <?=$faq->faq_answer?> </div>

Why do you want to have an ampersand in your urls? It's a special character used for defining get parameters so I don't think it's a good idea to have them in urls and I guess that's at least one reason why the sanitizer removes it from page names. Why not just use "blick-and-docker" as url segment?

One solution could be RockCalculator so that the client can easily calculate net from gross: So in austria they could enter 120/1,2 and would end up with the net value of 100. I really like to have that feature in some of my systems. Very simple yet very powerful. Another option is to hook the inputfield and add another input and some JavaScript: <?php $wire->addHookAfter("Inputfield(name=title)::render", function(HookEvent $event) { $field = $event->object; $field->appendMarkup = '<input type="text" name="foo"> <script> $(document).on("input", "input[name=title]", function(e) { let val = e.target.value; $("input[name=foo]").val(val); }); </script>'; });

Yes, that's possible. Create an autoload module and in the init method set the config options so that it uses different css files for different roles: https://github.com/baumrock/AdminStyleRock/blob/main/AdminStyleRock.module.php#L32-L47 $role = "get users role id"; $style = "/path/to/your/style-$role.less"; $compiled = "/path/to/your/style-$role.css"; PS: Just realized that you might not be able to access the user role in init() so maybe you need to use ready() instead. Hopefully that's not too late in the process but I think it should work.

$sanitizer->pageNameTranslate($page->getUnformatted('title'))

You can set that in the module's settings of InputfieldPageName:

Your usecase FAQ sounds like it would be a good fit for a repeater field. Add two fields to the repeater "question" and "answer" then you can add 1 to n items of FAQs to your page.

That's why I was asking for a generic example. I'd not be happy if lazyLoading was disabled by default. It's imho much better to add one single setting to old installations when needed (and I have not had any issues until now) than to have ProcessWire not use it's full performance by default. And don't forget updating old setups is a one time thing. I don't know how this feature works internally but I'm sure Ryan has made that decision thoughtfully.

@7Studio I don't understand. Which property can you not access? Can you give a generic example?

You are not dreaming - this is already possible using RockMigrations: <?php $rm->migrate([ 'fields' => [ 'myfield1' => [ 'type' => 'text', 'label' => 'My field one', ], 'myfield2' => [ 'type' => 'text', 'label' => 'My field two', ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'myfield1', 'myfield2', ], ], ], ]); If you don't like PHP arrays for whatever reason simply use json_decode( _your_fields_and_templates_as_json_string_ ) instead... I'll release a new version soon that makes it a lot easier to get started with RockMigrations though the API will 99% be the same as in the old module.

v1.0.1 removes the pw logo from the mobile offcanvas nav. before: after:

The truth lies in the middle of both code snippets ? If using Pages::saved you need to use setAndSave because if you only change the page property there will be no later save that actually saves it. If using Pages::saveReady as 3fingers showed you can use setAndSave but it's actually not necessary. You can simply use $page->yourfield = 'foo'; as the page IS actually saved right afterwards. Also I prefer to use early exists rather than a lot of if ... if ... if ... but that's a matter of preferance ? <?php $wire->addHookBefore('Pages::saveReady', function($event){ $page = $event->arguments(0); if(!$page->hasField("my_checkbox")) return; if($page->my_checkbox) return; $page->another_integer_field = 0; $this->message("This should have worked"); //for debugging only });

The backend is basically just a uikit navbar + content: https://getuikit.com/ You can simply include the backend theme files and use them for your frontend. You can even use the Less module and you get all the power of Less and variables etc. See https://github.com/baumrock/AdminStyleRock#how-adminthemeuikit-styles-work for details

I think the next step for debugging this would be to setup a new project without any modules other than tracydebugger and see if you can come up with a reproducable example. You can then share this custom page class with us and we can see if we get the same results and can help debugging.

Hey @ErikMH I haven't read everything in detail and I don't know what's going on here but my first recommendation as always would be to install tracydebugger. Once you have tracy you can do this: bd($this); bd($this->parent()); Then see what is shown in your debug bar (right bottom corner). Can you share that output with us? Are you maybe in a method that is called from a hook? Then $this would not refer to the current page so $this->parent() could lead to nowhere. Not sure why it would work on older versions of PW though, but at least that are some ideas.

Just released version 1.0.0 which makes it possible to set both the main color plus the logo url from within the module (without going to AdminThemeUikit settings): AdminStyleRock Easily style your ProcessWire backend with two simple settings: Or via RockMigrations: $rm->installModule("AdminStyleRock", [ 'rockprimary' => '#0069B4', 'logo' => '/site/templates/img/kollar.svg', ]);

No. All migrations will run again, but if you don't change anything they will likely not do anything. The good thing about this is that if something changed for whatever reason, the migration will change things back to the state that is defined in code. So for example if someone changed a field setting by hand, the migration would revert this change to what is stored in the migration. To make it more obvious that it might not be the best idea to change field or template settings by hand the new version stores a trace of the migration for every field and template and shows a warning on the field/template editor:

Somehow this does not work for me... I had to change the fieldtype to text which is less than ideal but as it's a private project I'll leave that for now... If anybody finds out something please let me know. I think it might also have something to do with locale settings. Dumping the value showed 1,23 but the value was not stored in the DB (sql error data truncated...). Weird.

Only option I know is plain SQL: <?php // populate test value $pages->get(1)->meta('foo', 'foo'); // find pages $result = $database->query("SELECT source_id FROM pages_meta WHERE name = 'foo' and data = '\"foo\"'"); $ids = implode("|", $result->fetchAll(\PDO::FETCH_COLUMN, 0)); db($pages->find("id=$ids")); If you use this with user input be sure to properly sanitize the data and maybe use prepared statements!

Ok sorry about that. I try to explain it in other words. What I meant was that if your system is blocked and does not respond to new requests it is likely that you have a process that is still running. This can happen quickly while testing SSE because you can quickly get into an endless loop and the process will run and run and run and block your system until the process is killed because it reaches max_execution_time for example. That's why I suggested to add a hard break while testing so that you exit after 30 iterations and the system will get ready for the next request. Hope that makes sense now? I'm not sure I understand. My usecase was simply trashing multiple pages or updating multiple pages via RockGrid (bulk editing). The user selects multiple rows and then clicks on an action (trash, update, ...). The user is then asked to confirm the action, which triggers the process of updating/trashing pages on the server. Now the only difference to a traditional approach is that this request is kept open using SSE and it keeps waiting for the server to receive the progress (eg trashing page 1 of 10, 2 of 10, 3 of 10... etc). Until this action is finished the system will be blocked for other requests of the same user (I don't understand how that works technically, but I think that other users can still request data from the server in the meantime?!). When the server is done with updating/trashing all pages it will send "DONE" to the client and the connection will be closed which makes the server ready for the next request. So it's a very special use case but it's also a quite common need! The example you are describing can not be solved using SSE as far as I understand. I think one would need sockets here. But I don't have any knowledge about them so I can't say anything here but I am happy to hear how that would work even if that is not really on topic any more ?

I guess nobody wants to hear that, because it seems to be too nerdy to create fields via code, but this is just another example why I love my setup so much. Thank's for reminding me of those days where I was struggling myself with those topics ? For those interested in an advanced approach of organising PW projects and keeping your setup clean I'll try to explain what I do for all my projects now. And that's another benefit: I always do the same. On every project. For every field. So every project works the same and I instantly know what's going on even if I haven't worked on the project for a longer time. For me these two things were crucial: Custom Page Classes (optional) RockMigrations (optional) RockMatrix or RepeaterMatrix If you haven't used custom page classes be sure to check them out: https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes That would actually take too long to explain... But I've shown some of the above mentioned techniques that might also be of interest for readers of this topic in the linked issue (https://github.com/processwire/processwire-requests/issues/154) The sort version which might be an idea for you guys having troubles with field names: You could create a custom class that is loaded in _init.php where you define your fieldnames as class constants: <?php // site/_init.php class MyProject { const field_body = 'body'; const field_teaser = 'body1'; const field_summary = 'body1'; const field_cover = 'blog_cover_image'; } Now you can access your fields in your templates like this: <?php // template newsitem echo "<h1>{$page->title}</h1>"; echo "<div>".$page->get(MyProject::field_teaser)."</div>"; <?php // template basic-page echo "<h1>{$page->title}</h1>"; echo "<div>".$page->get(MyProject::field_summary)."</div>"; Note that we are reusing the field "body1" and referring to it as "field_teaser" in newsitem and as "field_summary" in basic-page. Personally I don't do any reusing of fields any more but that's a different topic and relates to RockMatrix + RockMigrations. Hope the ideas where useful for someone nonetheless.

Thanks for making me aware of something that I've done wrong for about 20 years ?

Ok now we are talking about a totally different topic... But first things first. This is exactly what I'm using SSE for. The user clicks a button, ProcessWire starts doing a long running task (for example trashing lots of pages) and while it does so, the progress is sent to the client so that the client knows what's going on. I'd call that real world ? The reason why I chose SSE over sockets and over not implementing any client feedback is obvious: Having a long running task without a progress bar is just not an option. What if the user trashed several hundreds of pages and didn't know if that takes 5, 10 maybe 120 seconds? Other techniques are much more complicated to setup (for example web sockets). SSE is built in and does just what I needed: Inform the user of the progress of the task without polling. Of course while this task is running the system is blocked for all other requests. As far as I understand that's the nature of how PHP works. We have the same limitation everywhere in PW and everything in PHP... For example if you empty the trash with lots of pages and you try to visit the PW backend in another browser tab you'll also be blocked until the first tab has finished it's job - or am I wrong here? PHP is single threaded so if you wanted to come around this you'd have to do additional things. I've no experience in this territory, but this seems to look like it could be worth a try: https://stackoverflow.com/a/4350418 There's also https://www.php.net/Thread but that is based on a PECL. And so is https://openswoole.com/ which looks like it comes closer to what you are trying to achieve than what is possible with SSE as far as I understand. 1. Of course we are! Why shouldn't we?? The module is just here to have a common foundation to test things out and eliminate confusion about who copied which code snippet to whatever place etc.; You could now test the linked popen() technique and just add that to the module as a PR and everybody could understand and learn. 2+3. We'd need to have a real non-blocking background process for that. But as I said that not a matter of SSE that's a matter of multi threading in PHP. https://www.youtube.com/watch?v=spDpR2qr-Fs&ab_channel=Dr.RobertDimpsey So for my use case SSE seem to be a good option. For updating a website's content based on "real time data" polling might still be the better option as it will not block the user.

Well please try the module and see if that works first. Then try a custom approach and see if it breaks. The reason why I created the modules is exactly to avoid hickups when copy/pasting things from this thread or placing things in the wrong spot... So that everybody has a quick test of SSE with a single click (install module) and can proceed from there.