bernhard

Don't know if that's the issue, but you have a space at the end of your image path: As I've had problems with getting og:image to work with WhatsApp + ProCache and the reason was ProCache removing quotes I'd bet it doesn't like your space at the end as well.

Hey @gebeer thx a lot for your fix! Please download v2.2.2 🙂 The missing docs are also added to my website! 😎

Hi @Stefanowitsch thx for your interesting question 🙂 I think you have two options: Create a central event calendar and manage events from there Add the calendar field to the "group" template and then manage events as children of that group, eg "AA 12 Schritte" would show a calendar and there you create "January Meetup", "February Meetup" etc. I think the module should work for you already as it is. It has two hookable methods for modifying the events that the calendar shows on each admin page and the data that is used for each single event: Maybe we need to add another hook for the endpoint that creates recurring events, as this is at the moment hardcoded to use the current page as parent of new events, but that should not be a big deal. I think you could also combine both options: Have a calendar for every group where you manage the group's events. And have one central calendar that shows all events combined. Maybe that would be the easiest way to go, because on the combined calendar you'd have to code something that tells the calendar which group the created recurring events belong to. If you have a calendar directly on the group page then this is not necessary. But I'm happy to help you with anything you need and I'm sure we'll make it work 🙂 BTW: You have a design issue on your page at a special resolution:

Are you using ProCache with setting remove quotes if possible?

Hey @panx thank you for your question! I have added docs with an example implementation here: https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/frontend/

Hey @nurkka I'd second what @wbmnfktr said and recommend switching to modern css as much as possible. Or course it always depends on the situation and use case, but in general I think modern CSS is much more powerful. For example I've developed a website for a client where we have 3 different business units which have their own color (blue/green/yellow). This is called the "primary-color". Using css variables it is possible to switch colors easily across sections, so example.com/boats is blue example.com/outdorr is green and example.com/sunsails is yellow. So all I do is adding this: html { --col-primary: #ff0000; } Then I can use var(--col-primary) in my css and all colors will be changed. Using CSS variables instead of LESS has many benefits, for example: It will work with only one CSS file. The color will be set in the HTML. Using LESS you can only set @col-primary to ONE value. That means you'd have to create main-blue.css, main-green.css and main-yellow.css Using CSS variables it is even possible to set different colors for different sections on the page. For example on the frontpage we can show blog posts from all sections and depending on the section they belong to we can set a different color. But all cards will use the same CSS. All you have to do is this: <h2>Blog posts boats</h2> <div style='--col-primary: blue'> ... </div> <h2>Blog posts outdoor</h2> <div style='--col-primary: green'> ... </div> <h2>Blog posts sunsails</h2> <div style='--col-primary: yellow'> ... </div> This is very powerful and not possible in LESS/SCSS. I'm still using LESS for convenience, for example for RockPageBuilder it is still nice to have, because I can "namespace/scope" css via nesting, so that added css does not mess with global css defined somewhere else.

Have a look at FieldData::wakeup - it's stored in the _mxhidden prop.

Hey @BrendonKoz and anyone else following this thread, you might find interesting insights and examples in this thread:

I got great input from @BrendonKoz and @monollonom (and others) in the thread about RockCalendar development, so I thought I'd start a thread for RockCommerce too, as this module is finally taking shape 🚀 Today I implemented automatic image changing when a color option of the product is changed. This is so great, I had to share that!!! 😍 Now what is so great about this? The implementation! It will work with ANY frontend. Really. No matter if you are using Tailwind, UIkit, Bootstrap, whatever. All you have to do is to add a simple hook: // set image according to selected option ProcessWire.addHookAfter("RcVariationOption::enable", (event) => { // get the RcVariationOption instance const option = event.object; // get the image number from client input that is stored in rc-image attribute const image = parseInt(option.$rcattr("rc-image")); if (isNaN(image)) return; // find the thumbnail link and click it const index = image - 1; const link = document.querySelector( ".shop-gallery [uk-slideshow-item='" + index + "'] a" ); if (link) link.click(); }); Isn't that JavaScript code, you might ask? YES! 😎 I have totally refactored the JS implementation over the last week so that RockCommerce now uses the powerful concepts of Hooks that we know from PHP but in the JS world!! (See Let's bring hooks to JavaScript) I am in contact with Ryan to add this to the core once it is tested more. But so far it is really a pleasure to work with on both sides: First, when developing RockCommerce all I had to do to make the above shown hook possible is to make the enable() method of the RcVariationOption hookable by simply renaming it to ___enable() Second, it's also great for anybody using this module, as you can not only LISTEN to those events but you can also totally change the return value or even completely replace it's implementation. For example this is what I use to show custom prices based on the taxrate of the user visiting the website: ProcessWire.addHookAfter("RcProduct::priceTotal", (event) => { // get the money object // it's not a float, because 0.1 + 0.2 !== 0.3 in binary world! const money = event.return; // return the initial price plus the added tax event.return = money.times(1 + RockCommerce.getTaxrate() / 100); }); I've only been working with this new concept for a few days, but I already love it and can't believe I haven't implemented before! The next part to tackle is the cart 🤯😅 I'll keep you posted! PS: Anybody having an e-commerce project coming up or anybody interested in beta testing? Let's get in touch!

Ok one thing you have to be careful about is block visibility. What if an editor hides the contact block and add's another visible later on that page. I think your implementation doesn't account for that?

No, sorry, maybe {$wire->__text('foo')} works?

Hey @Sanyaissues thx for liking this post just in the right time! As of now we don't need any custom syntax any more for translatable strings in Latte files 😎 That's a side-effect of a recent request by @FireWire to make all native PW functions like wire() available in latte files and that also means that __(...) and _n(...) are now natively available in latte files as well! Just use <h1>{__('This is a translatable headline')}</h1> 🥳

Hey @gebeer please download v5.8.0 and use $page->rockpagebuilder_blocks->find('type=Whatever') 🙂 I also added this to the docs: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/api/ Would you mind sharing your use case? I've never needed this 🙂

I think the simplest solution would be to use a regular text field and additionally create a hidden datetime field. Then you add a hook on saveReady that populates that datetime field via something like strtotime(...). But it depends who inputs dates... only you? Or also others? Then you need to be more careful with input and maybe provide 3 inputfields, one for day, month, year. That could also be done with a hook.

Do you mean that the hidden field only get's updated when the page is saved in the backend and not when the block is edited via frontend editing? This is correct but can be optimised so that you don't even need a backend save. Are you using custom page classes for the page that the ArchiveFilter block lives on?

Hey @FireWire could you please try the latest commit of the dev branch, that should make wire() etc available in all latte files 😎

Ok while reading this I think it's worth sharing the other technique as well, as this might be even easier... The trick is to add a hidden field to your $page, like "post_author". That could be a page reference field. Then you add a hook on "Pages::saved" and you populate that field based on the $block's selected author. Then you can use a selector as usual: $posts = $pages->find("template=blogpost, post_author=123"); This has the benefit that you can use efficient queries and sorting etc. and you can rely on PW's find() for only finding published pages and such.

Hey @Atlasfreeman thx for your question. As you already mentioned correctly if the page reference field is in a block, when using a selector with that page reference field, you will get the $block and not the $page where the $block lives on. Let's say we have a block "Authors" and there we have a page reference field to select an author. We can get all these blocks like this: $blocks = $pages->find('my_author_field=123'); Then you can loop over these blocks and get the related $page: echo "<p>Blog Posts by this Author:</p>"; foreach($blocks as $block) { $page = $block->getBlockPage(); // maybe add some additional checks here, eg check if $page is published etc. echo "<div><a href='{$page->url}'>{$page->title}</a></div>"; } That should be all you need. If that is not performant enough because you have to query a lot of pages let me know and I'll show you a more advanced technique. Also it might be necessary to add something like "include=hidden" or "include=all" to the selector of the blocks, I'm not sure. If you need any more help with that let me know. Otherwise please share the working example once you are done and mark the topic [solved] thx 🙂

We have a new command to create modules 😎 The cool thing about it is that it creates all necessary files to get fully automated releases using the following file structure: This might be interesting for you @DrewPH

Great 🙂 Have fun!

Sounds like a nice module 🙂 Just a FYI there is also https://processwire.com/store/pro-dev-tools/wire-request-blocker/ which blocks unwanted requests efficiently via .htaccess 🙂

To be honest I'm not 100% happy with this feature either, but it is used on all of my websites and that would mean a lot of refactoring. There are several reasons why I built it like this (for example I advertised the module as "zero setup", so it needs to work without prior hunting through docs and adding scripts here and there), but there are also some problems that I didn't think of upfront. For example the current implementation does not work with template cache. RockFrontend has a setting for this in the module settings and now RockPageBuilder also has one. Please download v5.7.0 😎

This sounds like a perfect use case for RockGrid, if your clients have 65€ left (docs are under construction but if you need help I'm around). But again you have several options. You could also use regular page listers. Or you can use Lister Pro. When using RockGrid you get any table shown at https://tabulator.info/ Or you could create a custom admin page and build a custom tabulator yourself. It's not that hard if you know JS and HTML. RockGrid comes with a lot of extras, like SSE for bulk operations, action buttons (including ajax operations) etc., but if you just need a table then it's quite easy to just add a tabulator table to the backend. Oh, and we have the relatively new PageListCustomChildren

We always have to deal with exceptions, right? I'm always using the $rm->setPageNameFromTitle() helper that will update the pagename according to the page title on save. That's easy to do in a MagicPage: public function init(): void { $rm = rockmigrations(); $rm->setPageNameFromTitle($this); } But what if we wanted to make sure that one page has a custom page name that can't be changed, so that we can rely on the url eg in a fetch() call? public function onSaveReady(): void { if ($this->id === 6840) $this->name = 'versandkosten'; else rockmigrations()->setPageNameFromTitle($this); } We have to use the magic "onSaveReady()" method, because in init() and in ready() we cannot use $this to access the current page, because init() and ready() are triggered on a NullPage object and not the page itself. The reason for this is interesting but not for this post 🙂

Hey @nurkka thx for your questions! What do you mean exactly? Which modules did you install? This is expected. RockFrontend will only compile all .less files to one.css file. All other files will stay single files. This is because on some pages we might need some scripts, on others not. If all were compiled to one single file we'd have different files on different pages or we'd keep recreating this file over and over again when viewing different pages. At the moment no, for the mentioned reason. I thought about adding such a feature, but I think it would cause trouble. RF/RPB try to be as unopinionated about the frontend as possible, but some things need to be there to make it work. Can you please show me the content of these files?