Jump to content

szabesz

Members
  • Content Count

    2,513
  • Joined

  • Last visited

  • Days Won

    15

szabesz last won the day on January 6

szabesz had the most liked content!

Community Reputation

2,875 Excellent

About szabesz

  • Rank
    /sɑːbɛs/

Contact Methods

  • Website URL
    http://szabesz.hu

Profile Information

  • Gender
    Male
  • Location
    Hungary

Recent Profile Visitors

6,930 profile views
  1. This is great news, thanks Ryan! It really helps a lot as looking up new versions manually is very time consuming.
  2. 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.
  3. 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...
  4. +1 🙂 in case it is a feature request 😛
  5. 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!
  6. 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.
  7. 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....
  8. "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?
  9. 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...
  10. @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?
  11. @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?
  12. 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.
  13. 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 :) } }
  14. 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
  15. 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.
×
×
  • Create New...