szabesz

It does not matter whether it is positive or negative in this case. It is clearly politics: https://en.wikipedia.org/wiki/Politics Quote: It may be used positively in the context of a "political solution" which is compromising and non-violent,[".... Anyway, sorry for being off topic. I am not an administrator here, I just wanted to point out that you introduced something which is not inline with the forum rules.

@Torsten Baldes There are always downsides or caveats to any solution, more on this here too: https://processwire.com/docs/more/multi-site-support/ You can also take a look at the multisite modules' codebase to learn more or you can even roll out your own solutions (I am in the process of do it, too) if you have the time, of course. BTW, would you please refrain from breaking our Community Rules & Guidelines? Please, see: https://processwire.com/docs/more/multi-site-support/ "3. No discussion of politics or religion anywhere on these forums including the Off Topic boards - there are many other websites where you may discuss these topics." This means changing your profile image.

+1 I always read changelogs as well. Well, when one is provided... Side-note : ModuleReleaseNotes is great, the second non-core module I always install right after Tracy. As a companion module to ProcessWireUpgrade these two modules make the upgrade experience very pleasant. So if Pro modules also provided change logs then that would be great. This is an example form AdminOnSteriods: https://github.com/rolandtoth/AdminOnSteroids/blob/master/CHANGELOG.md Rendered like this:

This is great news, thanks Ryan! It really helps a lot as looking up new versions manually is very time consuming.

I recommend Stripe over PayPal. The simplest way to implement it is by using Stripe Checkout: https://stripe.com/en-hu/payments/checkout Once I have done that for a "one product only" site. This is the process in short: If visitor enters valid email address and provides quantity between 1 and 4 then he is allowed to proceed. ProcessWire sends an email to the site owner in the background with the email address provided and the amount in it, so that the site owner knows that someone initiated the process. Stripe Checkout comes up, customized with custom logo and a product image. Customer can either cancel the process or pay (also provides shipping info). If payment is successful, then customer gets confirmation message from ProcessWire and the bill from Stripe. That's all there is to it. The site owner can manage all the orders via the Stripe admin, nothing is stored in the ProcessWire database, not even the email address.

I do it all the time for any module no matter what ? and I also always force browser to refresh when a module possibly affects the admin, just to be on the safe side. I think I picked up this habit when I also failed to do it in the past for a Tracy update...

+1 ? in case it is a feature request ?

Not at all, it is just that – as I have wrote somewhere above – I keep an eye on your posts so I have read them all because I am interested. Especially as we are indeed talking about the same topic, it is just that we prefer somewhat different approaches to achieve something pretty similar, and I have already taken notes of your "tips and tricks". Thanks once more!

Yeah, I got that and thank you for that, however, I'm not keen on implementing modules for doing frontend development. Why? It is simply my personal preference. I perfectly understand if you build upon modules even for the frontend, however, that's just simply not my mindset. I appreciate that you spend the time explaining the benefits, whoever OOP can be done for the frontend even without putting any code into modules. The entry point is the page being rendered, from that point on, I can instantiate any objects I need to, there is no need for a module to do that. So that is why it is very important for me to be able to pinpoint the method that can be used to do custom initializations. So far I have not found any issues with using loaded(). If I find any drawbacks, then I will certainly ask for more help and ideas.

I just want to signal that I edited my post above, adding this: Taking a look at wire/core/Templates.php it is the getPageClass() method which determines the class of a page. Here, $corePageClass = __NAMESPACE__ . "\\Page"; is used to set ProcessWire\\Page as expected, except when there is a custom page class being used. Then, PW checks if a page class has been set "in the admin" and – if it is valid to use it – then uses that one instead. If no valid custom page class has been found so far, then PW looks for a valid custom page class supported by the new technique of PW 3.0.152+ (that is: extending it in our own client code) and this is where the class name ProcessWire\\DefaultPage is hardcoded into PW like this: $defaultPageClass = __NAMESPACE__ . "\\DefaultPage";. If this class is used/exits as a custom page class, then it is set to take over the pace of the core Page class, like this: $this->pageClassNames[0] = $defaultPageClass; and afterwards: $pageClass = $this->pageClassNames[0]; So my understanding is that by using the name DefaultPage to extend Page, one can "ask" ProcessWire to use it as the bases of almost all page objects, except for users, roles and permissions which are treated differently. Taking advantage of the possibility of using DefaultPage is optional of course, one can just simply extend Page by using any other arbitrary names, but the string literal DefaultPage named subclass is treated as the new core class in case one needs to add some custom behavior to all "non-user related" pages. Correct me if I am wrong but this is what I gathered sot far....

"regarding frontend custom page classes" Sorry for the confusing wording, what I mean is that I was not trying to compare the ___loaded() method of custom page classes to the the init() and ready() methods of a module's class and I am getting a bit confused that you started to discuss those methods as well, because module classes and custom page classes re unrelated in our case, aren't they?

Thanks Bernhard! Probably it was too late last night that's why I did not get that you were referring to modules, as opposed to using custom page classes for the frontend. My initial question about initializing such instance of the custom page classes was about the frontend only ones, that's what Ryan used to introduced them but he left us figure ourselves where to go from the basics. That's my main issue. Again, I was not referring to modules, that's clearly a different story. As far as the frontend is concerned, I found that ___loaded() gets called only once for each object instance an only when PW first instantiates the object. I will also look into the core where ___loaded() gets called to figure out more, but as far as the frontend is concerned, so far ___loaded() seems to be a good candidate to perform some custom initialization. Also, regarding frontend custom page classes, placing this into the constructor: $this->wire->addHookAfter("Pages::saveReady", $this, "onSaveReady"); seems to work as expected. On each page save, only the onSaveReady() method of the given instances are called (the ones that belong to the class), there seems to be no need to use filters to determine the object's class we are interested in. Again, all this applies to "subclasses of a direct subclass" on the frontend as I explained above, and doing the same for a direct subclass works differently, probably because the direct subclass takes the place of Page, and from that point on all PW Pages are "DefaultPage"-es, whereas subclasses of DefaultPage are not. I hope that makes sense...

@tcnet However, you block him from being able to publish it there in case he changes his mind. And even if he never wants to do that, it is confusing for the PW community that there exists two modules with different code bases and authors. Which module I am referring to now when I say: I like "ProcessFileManager"! Yours or his?

@MarkE Have you perhaps done anything "not so documented" besides simply placing your class files in /site/classes/? For example, in an effort to relocate the class files, I tried to do this: $classLoader->addSuffix('Page', __DIR__ . "/templates/abode/{$template}"); as suggested by @teppo over here but doing so somehow results in the behavior you describe, that is: there is no difference between direct subclasses and subclasses of those in this regard we are discussing right now. Can you please provide more details about what and how you are trying to achieve so that I can also test that?

Thanks for chiming in, Bernhard! I keep an eye on your examples, thanks for sharing! For example: v1 https://processwire.com/talk/topic/25114-membership-app-processwire-limitations-on-unique-records/?do=findComment&comment=211162 v2 https://processwire.com/talk/topic/21212-rockmigrations-easy-migrations-from-devstaging-to-live-server/?do=findComment&comment=212496 Can you please elaborate on this in a bit more detail? Maybe with some examples? I'm not quite getting it.

I have just posted about my findings regarding ___loaded(), see: https://processwire.com/talk/topic/25343-putting-page-hooks-in-page-classes/ Note that I used the latest dev (3.0.174) to do my testings. The issue is that same I described in my post, I think. ___loaded() gets called for any pages when using "direct subclasses" whereas going further down the class hierarchy, this is no longer the case. Regarding hooks, I found that applying them in the constructor works as expected, at least the following way: //direct subclass class DefaultPage extends Page {} plus: //subclass of direct subclass class ArticlesPage extends DefaultPage { public function __construct(Template $tpl = null) { parent::__construct($tpl); $this->wire->addHookAfter("Pages::saveReady", $this, "onSaveReady"); } //this one gets called as expexted upon saving the "Articles" page but not when saving others public function onSaveReady(HookEvent $event) { $page = $event->arguments(0); bd($page); //Tracy Debugger is required for this one :) } }

And here comes the first talking point I'd like to open... Ryan in his introductory article did not mention whether there is a significant difference between "DefaultPage as a direct subclass" of Page class and "other subclasses of DefaultPage". He also did not mention anything about the recommended way of implementing our own custom "initialization" method for the object, in case we need to perform such a thing. EDIT on 2021-03-28 starts ------------------------------ Taking a look at wire/core/Templates.php it is the getPageClass() method which determines the class of a page. Here, $corePageClass = __NAMESPACE__ . "\\Page"; is used to set ProcessWire\\Page as expected, except when there is a custom page class being used. Then, PW checks if a page class has been set "in the admin" and – if it is valid to use it – then uses that one instead. If no valid custom page class has been found so far, then PW looks for a valid custom page class supported by the new technique of PW 3.0.152+ (that is: extending it in our own client code) and this is where the class name ProcessWire\\DefaultPage is hardcoded into PW like this: $defaultPageClass = __NAMESPACE__ . "\\DefaultPage";. If this class is used/exits as a custom page class, then it is set to take over the pace of the core Page class, like this: $this->pageClassNames[0] = $defaultPageClass; and afterwards: $pageClass = $this->pageClassNames[0]; So my understanding is that by using the name DefaultPage to extend Page, one can "ask" ProcessWire to use it as the bases of almost all page objects, except for users, roles and permissions which are treated differently. Taking advantage of the possibility of using DefaultPage is optional of course, one can just simply extend Page by using any other arbitrary names, but the string literal DefaultPage named subclass is treated as the new core class in case one needs to add some custom behavior to all "non-user related" pages. Correct me if I am wrong but this is what I gathered sot far.... EDIT on 2021-03-28 ends ------------------------------ What I mean is the following: //this direct subclass of Page is treated differently class DefaultPage extends Page {} //subclass of DefaultPage class ArticlesPage extends DefaultPage {} Ryan in his article suggests that using DefaultPage as a subclasses can be used. However, I found a shortcoming when relying solely on DefaultPage. Let's consider this: //direct subclass class DefaultPage extends Page { public function ___loaded() { /* *___loaded() is called when the page is "prepared" by PW, having all its properties loaded from the database. * Because of this, it can perhaps be used as an init() method, so that * we might further initialize the object before actually using it in our own "client code". */ } } The issue with using loaded() to do our own additional initializations is that in the case of DefaultPage this method gets called for ALL the pages that are instantiated during a normal HTTP request. What I mean is that any code placed into loaded() will be executed for all sorts of pages, not just for our humble DefaultPage object we wanted to instantiate in the first place. Even worse – for some reason unknown to me –, the same DefaultPage object's loaded() method will be executed twice during a single HTTP request of the frontend. All this behavior renders loaded() unable to fulfill the role of an init() method I am looking for. However, I found that the subclasses of DefaultPage work differently, let's say "normally". While DefaultPage takes the place of Page as far as ProcessWire is concerned, any subclass of it does not. This is a very important difference, because the following one behaves differently: //subclass of DefaultPage class ArticlesPage extends DefaultPage { public function ___loaded() { /* * Code placed here always runs just once during a normal HTTP request. */ } } In this case loaded() only gets called by ProcessWire when our own client code triggers the instantiation of the custom page object in any way (for example when the related page is rendered by requesting it in the browser). And in this case no other custom page objects's loaded() method gets called. Moreover, trying to use Tracy (eg. a bd() call) in the loaded() method of DefaultPage is not possible, however, Tracy is readily useable in the loaded() method of a subclass of DefaultPage. To summarize: I found that in the case of a DefaultPage I cannot use loaded() as an "init() method". However, in the case of any further subclasses of DefaultPage, it looks like it is fine to rely on loaded() because it is called only once (after the object has been prepared for us by PW). I'm interested in hearing how others implement a custom initialization method for their custom page objects. Maybe there are better ways to do it than relying on loaded()? Is using loaded() for such a thing is a good idea in the first place? //de

Hello PW fans, I open this topic to pick up where Ryan left off in his introductory article. Note that beside the technique detailed in Ryan's article, there is another supported technique to use custom page classes (which is also mentioned in his article briefly), and you can learn even more about that one by – for example – reading this closed issue. I'm in the process of completely re-thinking the way I implement sites so I am interested in how others integrate custom page classes in their codebase. Let's use this forum thread as a general discussion board of this topic.

This is great idea indeed. Thanks for sharing!

Hi folks, Just stumbled upon this gem and completed the first two levels ? Looks entertaining indeed (at least for coders, of course...) https://www.i-programmer.info/news/90-tools/14431-oh-my-git-the-game.html Quote: "All in all, Oh My Git! is an intuitive game that really teaches you Git. ...[for those] who has ever struggled with Git." https://blinry.itch.io/oh-my-git Happy gitting ?

Peoples' life change and lots of us pick ProcessWire for our own freelancing projects and others use it because the company they work for uses it. When freelancing is no longer an option in one's life and/or one needs to work in another team/company then it often happens that ProcessWire is no longer an option either. I don't think that this has anything to do with PW losing traction or not. Ryan has already stated a lot of times that he wants to drive ProcessWire forward for at least the next ten years and even more... As long as he is behind the project, ProcessWire will be pushed forward for sure. He has also stated so many times that he is not interested in marketing shares and the like. He is also not interested in "growing it" in this regard. We need to live with this, ProcessWire is his baby after all...

Thanks for confirming!

Hello @teppo I have just updated the module from v1.5.4 to v1.12.0 and there were two schema updates in sequence: #2 and #3. Currently in the Changelog Hooks module's setting Schema version shows number 4. Does that mean that the schema updates were performed properly?

You can ask Ryan to re-publish it, see: https://processwire.com/talk/topic/24666-new-blog-processwire-modules-directory/?do=findComment&comment=212155

No more todo list in this file, looks like the release process is the next step perhaps...