bernhard

Ryan was quick with this one ? It's now easy and bullet proof: <?php $img = $page->get('images.first'); if($img) echo "<img src={$img->size(200,200)->url} alt=...>"; https://processwire.com/talk/topic/27528-weekly-update-– 2-september-2022/#comment-226391

Just for reference Ryan was very quick on this one and we now have this selector to force return the array value of an image field: $page->get('image[]')

Maybe you can trick it by using this? <!--# <!-- ko if: properties.ms == "pro" -->

No idea what's going on. But if you get an error 500 go and inspect your webservers error logs or the ProcessWire logs (in /site/assets/logs) and see if you find some helpful information there.

With document.ready I was referring to the javascript event that is fired when the DOM is ready. See here: https://stackoverflow.com/a/9899701/6370411 That has nothing to do with the server side ready.php file ? That's quite easy to do: <script> let infoShown = localStorage.getItem('medicalPopup'); if(!infoShown) { UIkit.modal(...).show(); localStorage.setItem('medicalPopup', 1); } </script>

Your examples are confusing. Your first snippet shows UIkit.modal().show() just before </body> and the second shows that you are loading the script just before </body>. So which one is true? The loading order is important, so if you do that: <script src="uikit.min.js"></script> <script>console.log(UIkit)</script> You should get a proper log in the devtools of your browser, but if you do that: <script>console.log(UIkit)</script> <script src="uikit.min.js"></script> You'll get "undefined" for your UIkit variable. So if you did UIkit.modal(...).show() in the second example you'd get the error that you described. What you can also do is to wrap your javascript in a document.ready callback: <script> document.addEventListener("DOMContentLoaded", function(event) { console.log(UIkit); }); </script>

I guess they are not, because that's what the error says ? How/where/when do you load UIkit?

I have created an alias command to get the same settings for all my projects ? alias ddc='ddev config --php-version "8.1" --database "mysql:8.0" --webserver-type "apache-fpm"' So for me its this: ddc --> setup a new ddev project git init --> initialise a new git repo git clone git@github.com:baumrock/RockShell.git cd RockShell php rockshell pw-install I should maybe create an alias for that too ?

Could any of the moderators please unpin this thread and also the captain hook one? The links are all 404 and I don't think that those projects still exist? At least I have not used them for years...

Hey @MarkE thx for your message! I'll answer in detail soon. Could you please describe exactly what you mean here? Best with a specific example from the very beginning until the very end. For someone that is not really familiar with your module please ? What do you do in code, what do you do in the GUI? Where? When? Why?... Thx

Something like this (from the docs)? <edit field="events" page="1001"> ... </edit> PS: ALFRED can help with FrontendEditing: https://www.youtube.com/watch?v=7CoIj--u4ps&t=1714s PPS: I don't really get the problem... Shouldn't it just be something like this? foreach($page->children() as $child) { echo $child->edit('body'); }

Sure, if you only need to store data and don't want (need) the overhead of creating fields you can just use json. Have a look at https://processwire.com/api/ref/page/meta/

I think that pages are a fundamental concept of pw and many things are built around that concept. If you think that storing data in pages is not a good idea, then you'll likely end up in a situation where you can not use some of the great tools that you can use when being aligned with pw concepts... That does not mean that one way is better or worse than the other. It always depends on the situation. But there are not many things in pw that are more fundamental than pages ? Imagine you want to add notifications whenever an entry changes. Using pages: $wire->addHookAfter("Pages::saved", function($event) { // send mail }); Using custom storage solution: No idea - I know why I'm using ProcessWire ?

As I've never had that need could you give some examples where you missed that feature? What could one build when having it? How would the workflows be then and how would they be now... Just to get an idea ?

I don't think so... Maybe I'm misunderstanding your message, but it looks like you are mixing things up. I'm not talking about using $this to refer to the current page inside the dedicated hook method. Of course, that would not work. Because in the hook method, as you have said, the context is different. And there you get the page by using $event->arguments(0) or similar. That's what I explained in the video and I never said something different. I'm just using $this in the init, because then I can be sure that I'm in the correct context. $this in init is the custom page class (or the page object), and I request the wire property of the page, which is always an instance of the current processwire instance. And then I call addHookAfter() No mixing things up. Inside the dedicated hook method (like "resetCache" in the example above) we are of course in the hook context. So $this would NOT be the current page there. But I don't see a problem here and I don't get your point?!

Those custom hook methods need to be public. It's not about pretending something. It's about keeping the code as easy to understand and therefore as easy to maintain as possible. If you put everything into a callback than it can be quite tempting to add a little bit extra code here and there, that actually does something different. Just because you want to do some additional logic and you think: "Well, I already have the hook in place... Let's add another line of code there". For example to change the "bar" property on page save. If you already have a dedicated method like "updateFooOnSave()" then it's much more unlikely that you add your BAR change there. Or at least you get reminded that it might not be the best idea... Hope that makes sense. Another thing you can do is to share the same logic and apply it to different hooks: <?php public funtion init() { $this->addHookAfter("Modules::refresh", $this, "resetCache"); $this->addHookAfter("Pages::saved", $this, "resetCache"); } public function resetCache() { // reset cache of whatever } We can do the same on newer versions of PW by attaching multiple hooks in one line, but I usually find it cleaner to be a little more verbose.

I'm using custom page classes a lot like modules. It's all about making things reusable to get more productive and to be able to increase quality step by step and not re-inventing the wheel from project to project...

Didn't think of using wire() - that would work. At least until you are using Multi-Instance. Or someone else uses it that uses your code ? And you still have to define the hooks as callbacks, which I don't like because of the reasons mentioned above.

Yeah it's hard to provide informations if you don't know who is watching... there might be total newcomers but some things might also be interesting for advanced users... Not sure how to tackle this... Hey @szabesz not sure what you tried, but I don't think that this can work. If you define a method as static you can't do object-related things inside this method. My IDE instantly throws an error: Static methods can be helpful for things like string-manipulations (eg Paths::normalizeSeparators()), but as soon as you need to work with objects (like pages and the wire object to attach hooks or such) you can't use static methods. I just did a little testing because having it defined static could have benefits, for example if there is no page created yet. In RockMigrations I solve that by creating a dummy page and saving it in the trash. Ugly but effective ? We could make the init static if we didn't use $this to attach the hook. But then we'd need to provide the wire instance as parameter (which is kind of clumsy imho). Also, we'd need to define the hook in a callback instead of placing it in a custom method of the pageclass (because we can't access the pageclass from a static method): So if we did all that, the init method would get quite bloated. Also I try to avoid defining hooks as callbacks, because they are harder to debug! See Tracy's "hooks triggered" section: That's the reasons why I put all the hooks in the pageclass's init() but make all of them a custom method in the class ?

Maybe you don't have an admin user with the default ID 41... foreach($users as $user) { echo "{$user->name}, superuser: {$user->isSuperuser()}<br>"; }

Do you think it is better on the latest video? I didn't want to make it bigger... it feels so... strange ?

Ok, just wanted to mention that the user switcher is not available on my end when I'm a guest ? Ok thanks, of course that's very sensitive topics and every caution is good! Don't let yourself be pushed in a direction you don't want ? But if it's easy and secure to add I'd be thankful ?

I'd have used the one that is in $config->superUserPageID which is 41 usually... Or it could simply do a $users->get() to return the first superuser it can find? I don't think that this is anything worse than what we already have... I just doublechecked and my tracy bar is shown for guest users on local dev and I can use the console for whatever I want. So a superuser-login-button would not hurt imho? ? Thx for the tweaks on the user switcher!! I was talking about the login-link in the bar: Looks like you have already setup a redirect feature here? If I visit page /foo on the frontend, then click "login" in the tracy bar I come to the login screen and after login I'm back at /foo When using the regular login the process is different: Visit /foo on the frontend --> go to /processwire --> login --> see the pw page tree (or dashboard) --> go back to /foo (manually)

Thx ? Thx for the reminder, I linked the post in the video description! Yesterday I implemented another way of doing the same principle into RockMigrations. RockMigrations has had the initClasses() method, but you had to call that manually and provide the correct namespace. With yesterday's update you simply let the custom page class use the MagicPage trait and RockMigrations will autoload the pageclass on boot and trigger init() and ready() on the correct timing. I didn't want to put that into the video though as it's a very young addition and I've already had to fix some things today. But it looks like a very promising approach to me ? Thx, I'll try my best. It's quite a lot of work, but it's fun.

Thx for the inspiration - this is for you ?