ProcessWire.rocks! My youtube channel

[szabesz]

Hello @bernhard! Thanks for sharing!

10 hours ago, bernhard said:

Do you think it is better on the latest video? 

Great and informative. Though, for complete newcomers to PW it might not be detailed enough, but if someone does not understand something then they can always ask :)

BTW, your init() method is not static. Is there a reason for that? Since $pages->get("template=quote")->init(); returns the first such page PW finds, it does not matter which page is that. If it does not matter, then a static init() method would also do the trick, wouldn't it? At least it works for me that way, too.

This init() method of yours does not initialize a page object as such, instead, it can be used to organize code which attach hooks related to the template class in question, and not related to a particular page (object). When dealing with a page object in the hook's functions, then that is a different matter, of course. Or is there anything else that (apart from attaching hooks) you sometimes put in this init() method?

 

[bernhard]

1 minute ago, szabesz said:

Great and informative. Though, for complete newcomers to PW it might not be detailed enough, but if someone does not understand something then they can always ask ?

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...

2 minutes ago, szabesz said:

BTW, your init() method is not static. Is there a reason for that? Since $pages->get("template=quote")->init(); returns the first such page PW finds, it does not matter which page is that. If it does not matter, then a static init() method would also do the trick, wouldn't it? At least it works for me that way, too.

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 ? 

[szabesz]

Can't you just use wire() instead of $this->wire? What we are talking about is not a "module context", after all. I always use wire() when not dealing with a module.

[bernhard]

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.

[bernhard]

5 minutes ago, szabesz said:

What we are talking about is not a "module context", after all.

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...

[Spinbox]

On 8/30/2022 at 11:00 AM, bernhard said:

Thx for the feedback @Spinbox I'll try to do that! ? Would you need an explanation of the concept of migrations in general or would that be too much?

A short explanation would help anybody not familiar with the concept

11 hours ago, bernhard said:

Do you think it is better on the latest video? 

I didn't want to make it bigger... it feels so... strange ? 

Great stuff, this helps a lot ? Easy to understand and definitely going to start using it.

[szabesz]

1 minute ago, bernhard said:

I'm using custom page classes a lot like modules.

I think that is why you "mix things up". You do not need to use $this just to attach a hook in this context. We do not get access to a page object in the hooked function via $this, instead we use $event->arguments(0). This is because strictly speaking these are unrelated code bits. Sure, organizing them under the class is very useful, but even though related functions are neatly organized this way, the methods attached by the hook live in a completely different context than the ones that are meant do be called directly via a page object. I hope I could clearly explain myself...

8 minutes ago, bernhard said:

Didn't think of using wire() - that would work. At least until you are using Multi-Instance.

Are you referring to $site = new ProcessWire('/path/to/www/'); perhaps? See: https://processwire.com/blog/posts/multi-instance-pw3/#using-multi-instance-in-pw3

In that case the site instance in question must be accessed via the variable the reference is store in (via $site in this example) which is a special use-case for sure, but are you really sure that what I proposed would not work in that context? Sticking to Ryan's example, if we do $site->pages->get("template=quote")->init(); then we already got the right context, so why would putting wire() in that init() method not work which is a different context?

Again, we are merging different contexts under the same PHP "class code" and we need to keep in mind which context we are in because they are not the same.

[szabesz]

2 hours ago, bernhard said:

And you still have to define the hooks as callbacks, which I don't like because of the reasons mentioned above.

Yes, that is true but since the functions called by the hooks are not to be called directly on a page object, is it that important to "pretend" that they could be called like that? I never use Tracy's "hooks triggered" section. In what scenario you take a look at it, regarding your own code? I am just asking to learn from your experiences...

Anyway, if we use an object method as opposed to a static method, perhaps that method should be protected as it is not intended to be called "from outside". What do you think?

Edited September 1, 2022 by szabesz
typo fixed "to learn FROM your experiences..."

[szabesz]

9 minutes ago, szabesz said:

if we use an object method as opposed to a static method, perhaps that method should be protected

Asking about the method being protected was not referring to the init() method but the one provided for the addHook method, of course (the one used instead of a closure).

[bernhard]

1 hour ago, szabesz said:

Asking about the method being protected was not referring to the init() method but the one provided for the addHook method, of course (the one used instead of a closure).

Quote

// inside a class (if 'myHookMethodName' is a public method of class)
$this->addHookAfter('Class::method', $this, 'myHookMethodName');

Those custom hook methods need to be public.

1 hour ago, szabesz said:

Yes, that is true but since the functions called by the hooks are not to be called directly on a page object, is it that important to "pretend" that they could be called like that?

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.

[bernhard]

4 hours ago, szabesz said:

I think that is why you "mix things up". You do not need to use $this just to attach a hook in this context. We do not get access to a page object in the hooked function via $this, instead we use $event->arguments(0). This is because strictly speaking these are unrelated code bits. Sure, organizing them under the class is very useful, but even though related functions are neatly organized this way, the methods attached by the hook live in a completely different context than the ones that are meant do be called directly via a page object. I hope I could clearly explain myself...

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?!

[bernhard]

Hm... Just had the idea that it would be nice to have the domain processwire.rocks for my channel with that name...

My channel was created on 21.07.2022, the domain is taken by someone else and has been registered on 06.08.2022... coincidence? 

who.is leads to namesilo, which shows a "try to buy" button... https://www.namesilo.com/domain/search-domains?query=processwire.rocks

that.sucks

Any ideas for a better name + domain are welcome! I guess I'll have to register a domain BEFORE starting the next channel ? 

[wbmnfktr]

3 hours ago, bernhard said:

that.sucks

That domain is already taken as well.

Yet... in case of domains... you should know who to ask first.

[bernhard]

New video is out: Quickstart for RockMigrations ?

[gornycreative]

This is great stuff - I love seeing how other folks work their process and it always gives me new approaches to try. I hadn't messed with latte at all before these videos (always got stuck using smarty and twig) but the simpler syntax looks awesome. Thanks for the work you've put into these modules and the videos!

[bernhard]

Thx @gornycreative really happy to hear that! ?

[gornycreative]

On 8/5/2022 at 6:44 AM, bernhard said:

What do you guys think of the forwarded sections with 200/300% speed? Is that a good solution?

In terms of cleanup? Cleaner to leave it on the floor. I think the random commentary bubbles and stock are funny though. It's hard to spice up dry material like coding, but I felt like these video have a good pace - I've watched them all through.

[bernhard]

New video is out ? 

[Spinbox]

On 9/18/2022 at 11:41 PM, bernhard said:

New video is out: Quickstart for RockMigrations ?

Great! Was about to dig into RockMigrations tomorrow. So happy to see you so active! Thanks a lot!

[bernhard]

These videos are so much work 🙈

I have tried a different software and a different technique. What do you think?

 

[wbmnfktr]

Using those aliases for DDEV, Git, RockShell makes the first 2.5 minutes kind of... blurry or a blackbox or something.

Even though I know how to install ProcessWire with a custom site profile I had to watch it a few times to understand whats happening.
While I use DDEV, I use way different aliases, i don't use RockShell, and so on.

It felt a bit like installing Laravel or CraftCMS to me - so many different moving bits and I don't know or can't really follow as I don't have or use the tools and can't see what really happens.

As mentioned elsewhere: I love the fact ProcessWire has still ZIP files and don't relies on composer to install something.

It would have been nice to see a slide with the full DDEV command, a screen with the Github page and URL to see where I can get the profile as ZIP.
After that I would have preferred to see a full clean install with unzipping a site profile, dragging it into the docroot, and go from there.

If I were new to ProcessWire this would have freaked me out in terms of: that's a lot of hoops I have to jump through.

[bernhard]

Hey @wbmnfktr thank you very much for your honest feedback!

I had to think about what you said, because I had good reasons (at least I thought they where good) for using my advanced techniques. I didn't think that showing a very basic, old-school installation via unzipping the module files would be interesting at all, so I wanted to pack more into the video. Not that old-school installations are bad in any way, I just didn't think that this is interesting or helpful for anybody.

Also I thought I made it clear that this is nothing anyone has to use, but I think that got lost during editing.

So I think you have a very good point and I'll try to not mix different topics in one single video. These alias commands would have been more helpful in a dedicated RockShell video, I guess, where I also show how these can be setup.

Thank you!

[wbmnfktr]

18 minutes ago, bernhard said:

Also I thought I made it clear that this is nothing anyone has to use, but I think that got lost during editing.

You said that loud and clear, yet my point here is this:

Installing a site profile is a very basic task. Well, it's actually just installing ProcessWire with one additional step.
But you made it look very complicated. I'm fine with it, even though I had to watch it a few times to know what happening, because I know the "real" steps.

A RockShell or DDEV video with that first 2.5 minutes as a demo - perfect!

Another thing I noticed but didn't mention the last time was the sound. In some parts your voice shifts as if you have sped the video up. Not sure if this was intended or not.

[bernhard]

I've recently hit 10.000 views on my youtube channel (over all videos since the beginning 2+ years ago) 🥳

I'm counting 218 subscribers and all have watched 800 hours of (almost only) ProcessWire content.

The best performing videos so far are:

Recent videos have been by far less popular. I don't know why. Maybe it's the thumbnail. Maybe the video length (the RockFrontend video is over 40min long!). Maybe it's the algorithm. Who knows.

But Ive learnt a lot and recently I found a way to be more efficient with creating those videos - unfortunately I didn't get any feedback in that regard, but feedback is rare on my channel in general. Maybe that's part of the youtube game 🙂 

So I'm asking here:

What is your opinion about these videos?

Are the videos helpful? Could anything be improved (easily 😅 )? What would you like to see as a next video?

• RockMigrations Deployment
• RockMigrations in general
• More about RockFrontend
• More about the commercial modules
• Less about the commercial modules
• Anything else?

Thanks for "watching" and have a great weekend 🙂