szabesz

This resources list might also help you to get started: https://processwire.com/talk/topic/26720-using-echo-with-delayed-layout/#comment-221298

This is a nice showcase to demonstrate that even one of the oldest tutorials are still relevant today. ProcessWire is evolving in a way that basics never change and even backwards compatibility can be relied upon. Sure bugs come and go, but there is no complex software without bugs. Anyway, my recommendation form 2019: Not to mention: https://www.pwtuts.com/tags/ And some up to date tudorials from 2022: https://www.youtube.com/channel/UCvp33AwVHgFKgsrGaLh-ANg/videos Hope this helps.

@bernhardSorry for watching but not seeing :) since you just posted the module in the post above, there is no room for configuration, I see. Maybe the idea calls for a full-fledged module?

Hi Bernhard, thanks for sharing! Not a better solution but something that lessens the severity of the whole issue is built into Bootstrap 5: https://getbootstrap.com/docs/5.2/getting-started/rfs/ which is a separate project so not tied to bootstrap: https://github.com/twbs/rfs/tree/v9.0.6 Using RFS means that there is less need for hyphenation but still there is, of course. Also, RFS makes it easier to adapt other values on the fly, if needed. I have not yet installed the module (I will, when I have the time) but 3 dashes look odd to me. I would rather use only one character for that (underscore, maybe). So, if you could make it configurable that would be great, I think. (If it is not yet configurable, perhaps...)

I've been successfully using Dark Reader for years, with these settings (Filter+ is need for my Mac so that coping text still results in the original colors, not the changed ones of the view):

Thanks in advance for releasing it for free! While I am pretty sure it will serve as good example (which I can't wait to learn form) and as a solid base to build upon, I wish there was a way to upgrade site profiles, similar to module upgrades.

@Robin S Thank you!

It is useful for sure! Thanks for sharing! One quick observation: Could you please consider placing the output of the module under the "Add New" button instead (along with some margin-top)?

Hi, hope this helps: https://processwire.com/talk/topic/15282-help-for-first-project/#comment-136758

Ryan has already stated lots of times that he is not interested in growing the user group just for the sake of growing it. In other words, it is very low priority for him, as far as I understand it. He is also not interested in page builders as such, but happy to add features to Repeater Matrix that support such use cases whenever he has the time to work on it. I guess that will be the closest to "page building" from Ryan. "Theming" will certainly never be possible with ProcessWire as a core feature as that would be agains its philosophy, wouldn't it? A solo or a team of developers can surely come up with their own theming schema and implement it for themselves but that is a different story, I think.

Hello, Let's say that is the simplest way to do it. A couple of other ideas that might or might not suit your needs if you upload an image representing the PDF: https://processwire.com/modules/inputfield-selectize/ Pages selectable via Inputfield Selectize can have their own PDF files uploaded to them and that way you can make those PDFs sharable across the admin. There are similar modules for images only but they are probably not what you need. https://github.com/gebeer/FieldtypeImageReference https://processwire.com/modules/inputfield-select-images/ (you might want to consider to borrow form the idea of this module and implement something like this but for non-image files) Hope this helps.

Also related:

Capturing the amount is about manually trying to prevent fraudulent transactions, because by not finalising the whole transaction in one go, the shop owner can intervene and decline the payment. This way there is no need to do a full refund later on, which is costly. On the other hand, a person manually checking each transaction takes time, which is also costly... You can probably learn more here: https://stripe.com/payments/payment-methods-guide 2.1 For e-commerce and marketplaces Recommended: Cards, wallets, bank redirects, "buy now, pay later"

You are right. I forgot to mention that for sure. I guess, too :) BTW, I do not think sarcasm is a wrong thing as such, I just felt it a bit off topic in this context but that was just my impression, of course.

The biggest difference is that Robi's module uses php files while Kongondo's module saves the php code into the database so you need to code in the admin. I used them both, so I recommend Robi's module. I have already switched sites from Runtime Markup to Runtime Only. These are possibilities for sure (BWT, I do not think Ivan is afraid of writing code so why the sarcasm?), but what a simple buildFormContent hook will not do for us is being able to use the rendered output anywhere where an Inputfiled can be used (in a Lister or a ProField Table, etc, for example). So we are comparing apples to bananas if we compare inputfields to code running in hooks. ;) Both can be valid options, we decide what to use depending on the requirements, of course.

Hello, In sort, you can do something like this in a saveReady hook: if($page->template == 'yourtemplate') {... It is also possible to use a "shortcut", like this: $wire->addHookBefore("Pages::saveReady(template=yourtemplate)", function($event) {... https://processwire.com/docs/modules/hooks/ Quote: Some hookable methods in ProcessWire have no implementation and exist purely for you to hook. Because hooks like this exist purely "to be hooked", it doesn't matter if you hook before or after them. Examples include Pages::saveReady which is called after it's been determined the page will definitely be saved, but right before it is done. Another is Pages::saved, which is called after a page has successfully been saved. These hooks provide more certainty and less need for error checking than hooking before or after Pages::save. You may see several other specific-purpose hooks like this in ProcessWire. Ryan in a pro module support thread provided this general example for repeaters, for example: Quote: A Pages::saveReady hook is your best bet for populating the value of some field on a page before it is saved. If you wanted to populate some page reference field on a repeater item when it is saved, you could do so like this in your /site/ready.php file. In my example below, I'm populating some_page_field with the page that owns the repeater item, since I think this is what you were trying to do (?). You'd want to update the first 2 lines to reflect your actual repeater template name and page reference field name. $pages->addHookBefore('Pages::saveReady', function(HookEvent $event) { $templateName = 'repeater_template'; $fieldName = 'some_page_field'; $page = $event->arguments(0); if($page->template == $templateName && $page instanceof RepeaterPage) { $ownerPage = $page->getForPage(); $page->set($fieldName, $ownerPage); } }); More examples: https://processwire.com/talk/topic/26897-add-new-set-title-of-new-page-with-a-select-field-combination-pagereference/?do=findComment&comment=222469 Modifying field values is easy, but if you need to do it based on the values of other fields then things might get "tricky" sometimes, depending on the types of those fields.

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

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?

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

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.

Hello @bernhard! Thanks for sharing! 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?

BTW, haven't you considered using PW's $session API variable instead? You could simplify your code considerably.

Yeah, later on I realized that I had been a little bit late to the party...

Thank you, @fruid!

I think @fruid wrote a good short introduction above, he just missed a short "birds-eye view intro" explaining the bigger picture. I skimmed through the code of the module(s) and it is not that hard to see what the module does in general. If someone is really interested in it, then it is best to install it on a site that loads UI-Kit 3 and try in out. What @fruid could really add to his intro above is a short video, showcasing what the module does in action.