Leaderboard

This IS NOT related directly to ProcessWire code. A critical CVE vulnerability was found in ZLib. Posting here in case some of you manage dedicated servers, and/or for checking if your hosting provider(s) do their job. more information: https://nvd.nist.gov/vuln/detail/CVE-2022-37434

Do you think it is better on the latest video? I didn't want to make it bigger... it feels so... strange ?

Thank you for letting me know that they exist. I'm not even going to test them ? More seriously, the only thing I personnaly "miss" it's an official SomethingBidule_API core module maintained by @ryan . In the meantime, @Sebi is doing a great job, we just need people who want more functionalities, or rather something "more" solid, to do pull-requests.

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?

Page Table was developed/intended as a part of the ProFields bundle, but later bundled with the core package, so "ProFields" in the name is kind of a nod towards that history ? There are many ways to handle rendering, but here's one solution that may help you: Create a shared root for your content elements — something like /blocks/ or /content-elements/, perhaps. Configure your Page Table field to save new items below aforementioned root path, and make sure that you only enable templates that you've created for this purpose. You don't want to allow a "regular basic-page" (or anything like that) in your Page Table field as a "content element". For each of your "content element templates", leave template file empty (so that these pages can't be reached with their actual URL). Now even though your content elements will be actual pages in the page tree, they won't be reachable by visitors. You can render them in any way you see fit, but here's one approach using ProcessWire's native field rendering feature that, in my opinion, works pretty well. Here I've assumed that the Page Table field is called "blocks", and it's used on template called "basic-page". /site/templates/basic-page.php <?php namespace ProcessWire; ?> <?= $page->render('blocks') ?> /site/templates/fields/blocks.php <?php namespace ProcessWire; ?> <?php foreach ($value as $item): ?> <div class="block"> <?= $item->render(__DIR__ . '/blocks/' . $item->template . '.php') ?> </div> <?php endforeach; ?> /site/templates/fields/blocks/block_template_name.php <?php namespace ProcessWire; ?> <h2> <?= $page->title ?> </h2> <?= $page->content ?> Anyway, as I mentioned that's just one approach ? I'm not entirely sure what you're referring to here, but if you mean the processwire.com website, then yes — that's technically proprietary. In my experience that's a common thing for open source projects. API reference, on the other hand, is automatically generated from ProcessWire's source code, so that is technically open source ?

I'll share my youtube videos in this thread and if you have questions this is the place to ask. You can also subscribe to this thread to get notified when I post new videos ? Here is the link to my channel: baumrock.com/youtube --- Hey! I've just published my very first ProcessWire video. It's about RockFrontend: https://processwire.com/talk/topic/27417-rockfrontend-??-take-your-processwire-frontend-development-to-the-next-level/#comment-225666 Here is the video: What do you think? Do you understand what I'm trying to explain (despite the many ääähms und öööhms...)? ? What about the length?? I really didn't plan do get to 40mins... Did anybody even watch it till the end? ? Would it be easier to follow when having a small thumbnail in the bottom corner when working on the code? Or better without? Is it worth the effort of creating a video or would a readme be just as good? ? Any tips for better sound/lighting? I'm not really knowing what I do, so any ideas for improvements are very welcome ? Better with or without background music? So many questions... So much to learn... ? But it's fun and I'm a bit proud ?

Something like this (from the docs)? <edit field="events" page="1001"> ... </edit> PS: ALFRED can help with FrontendEditing: https://www.youtube.com/watch?v=7CoIj--u4ps&t=1714s PPS: I don't really get the problem... Shouldn't it just be something like this? foreach($page->children() as $child) { echo $child->edit('body'); }

thanks! I will try that there's a typo BTW // set and save a meta value $page->meta()->set('colors', [ 'red, 'green', 'blue' ]); missing a '

Sure, if you only need to store data and don't want (need) the overhead of creating fields you can just use json. Have a look at https://processwire.com/api/ref/page/meta/

I think that pages are a fundamental concept of pw and many things are built around that concept. If you think that storing data in pages is not a good idea, then you'll likely end up in a situation where you can not use some of the great tools that you can use when being aligned with pw concepts... That does not mean that one way is better or worse than the other. It always depends on the situation. But there are not many things in pw that are more fundamental than pages ? Imagine you want to add notifications whenever an entry changes. Using pages: $wire->addHookAfter("Pages::saved", function($event) { // send mail }); Using custom storage solution: No idea - I know why I'm using ProcessWire ?

As I've never had that need could you give some examples where you missed that feature? What could one build when having it? How would the workflows be then and how would they be now... Just to get an idea ?

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

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.

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

Maybe you don't have an admin user with the default ID 41... foreach($users as $user) { echo "{$user->name}, superuser: {$user->isSuperuser()}<br>"; }

Forum for now. Would have wanted GitHub (or similar) but the issue is that this is not an open source project. No easy way to report bugs that I can think of given the situation. Good catch. Silly oversight on my part then. This will also affect products with variants and attributes. I'll fix today and re-issue as 005.

Personal opinion: I think if I were to make a decision on what I see about Payload, I'd probably (personally) opt for Statamic for two reasons: I'm more familiar with PHP, and since it's a file based CMS and can be run directly from a Git repository, it makes things simpler (even if the installation is, IMHO, ridiculously bloated: thanks Laravel). I see some level of inspiration in it by Statamic, Kirby, and maybe Wagtail, but obviously with its own take on it all. For Directus: I don't personally see that as a CMS - or at least CMS-first option. If I remember correctly (I might not), it was originally advertised as a visual data query builder, enabling the ability to connect to an absurdly large amount of disparate datastore solutions, and then (visually) build queries to concoct interfaces and/or reports related to that data. Can you build a CMS with it? Apparently so! Should you build a CMS with it? I suppose that depends on exactly what it offers. I haven't personally tried it, even though I've kept my eye on it in case I had a project that seemed to fit. So far I (unfortunately) haven't. (I kind of want to play with it. It looks ridiculously powerful.) All that said, I haven't tried either, so my involvement isn't exactly what you were hoping for. As far as RestAPI and GraphQL, are the related modules insufficient? (I know you said default modules, so my curiosity is only adjacently related.) I definitely enjoy comparing and re-evaluating tools though, so appreciate this hashed, and rehashed, and rehashed topic! ?

I've edited my statement from 2019. Ryan has already pulled in several contributions and said he is happy to add others. So I think while it does not happen very often (which has the benefits that @pwired mentioned) it is not true (any more?) that PRs are ignored ?

I am on mobile, so short answer. You can define your own error handler with `set_error_handler`. (Do not forget to restore the default handler, check the php doc.) Example: function send_email_on_notice() { … } set_error_handler("send_email_on_notice", E_NOTICE); […] restore_error_handler() Consider testing the behavior of it if you use it on a try/catch block.

Another example of creating fields/templates during module install: https://github.com/apeisa/Discussions/blob/master/Discussions.module#L280. That code is 10+ years old and a bit verbose, but that's exactly why it's (in my opinion) a good example. No abstraction layers, no potentially confusing shortcuts, etc. ?