szabesz

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.

As we all know, Google's services are never free, we all pay by providing our own data to them: https://thehackernews.com/2022/01/german-court-rules-websites-embedding.html and we never know what they are using our data for, but this monkey business is quite profitable for them for sure.

Hello, see: https://processwire.com/docs/front-end/output/markup-regions and https://processwire.com/talk/topic/23641-markup-regions-pw-vs-data-pw-different-behavior/#comment-201538 hope this helps

@kixe Thanks for sharing the module! Is there a related github issue perhaps? The only decimal field related issue is this one (as far as I know): https://github.com/processwire/processwire-issues/issues/1341

If you are OK with linking to posts of this forum, you could just simply include a line or two like: "You can read more about realted topics at 'here' and 'there' etc..."

Old question but I have just had to do the same so for those looking for this answer in the future, you might want to do something like this: https://stackoverflow.com/questions/16251625/how-to-create-and-download-a-csv-file-from-php-script#answer-54433375 The key parts to implement are: the headers, handling the output buffer, fopen( 'php://output', 'w' ), and exiting at the end. The rest must be implemented as you see fit. EDIT: it might be better to export data into an excel file, for example when non-ASCII characters are in the text data. I found this package to export to excel with only two lines of code: https://github.com/shuchkin/simplexlsxgen (for CSV see its sister project https://github.com/shuchkin/simplecsv) $xlsx = SimpleXLSXGen::fromArray($array2D); //the array to be expored is prepared in advance $xlsx->downloadAs($filename); //initiates the download

Some notes on this topic: The example above in the spoiler does not seem to work as expected (ProcessWire 3.0.184). What works for me is this: https://github.com/processwire/processwire-issues/issues/675#issuecomment-420958397 Also worth reading this discussion: https://processwire.com/talk/topic/19781-issue-with-hooking-processpagesearchexecutefor-and-the-new-search-feature-in-pw-30108/

Note: the variable $process is undefined in my case, running PW 3.0.201. I used this instead: $page = $event->object->getPage(); // Page that was edited/saved

Something like this is already supported by @adrian's Module Settings Import / Export module which I recommend.