bernhard

Hey @nurkka thx for your question! I think that I just changed this as some point in time as I've never really been using the sort feature. It turned out to be less useful than I thought and having them sorted alphabetically with a filter input seemed the better option. I think it should be quite easy though to restore the old behaviour via config setting. Would that help? Or are you just playing around with it and I can remove that info from the docs? This is unfortunately not possible at the moment 🙈

Maybe these links help? https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks

Just wrapped up an epic RockCommerce meeting! 🤓💻 We dove so deep into nerd talk, I think I saw binary code floating by at one point. Pretty sure we accidentally invented three new programming languages and a quantum computer while we were at it. Big thanks to everyone for their feedback and help! 🙂 Stay tuned, fellow wire-processors! This community rocks! 🎸 😎

I just watched a video about e-mobility and comparison of different energy sources like petrol, e-fules and batteries. Don't want to start a discussion here as it would also violate forum rules, but seeing this picture I thought this look so much like the comparison between a typical WordPress site compared to a typical ProcessWire site 😄

I'm not sure I understand your question. A site profile is not a backup. But it depends how you use it and what you use it for. So it might be enough or might not be. I'd say 90% yes, should be enough.

@Stefanowitsch is already implementing the module in the mentioned Project: Now the question arose how one could add an event schedule like "Every last Friday of the Month" With the current settings this was not possible: Version 1.1.0 adds some more options to the dropdown 😎 https://www.baumrock.com/releases/rockcalendar/

Hey @Atlasfreeman backup your files + db download the latest version you have access to replace the /site/modules/RockPageBuilder folder if needed also update RockFrontend and RockMigrations

Hey @gebeer sorry for the confusion. Just realised that you were talking about deployments and I was working on the releases 😄 I have also updated the deploy workflow to use checkout v4 instead of v3 which fixes the nodejs warning! So this is what you can use for automated releases: name: Auto-Release on: push: branches: - main jobs: auto-release: uses: baumrock/RockMigrations/.github/workflows/auto-release.yml@main secrets: token: ${{ secrets.GITHUB_TOKEN }} So whenever you push to main it will create a new release for you with automated release tags and changelog. And then I have this workflow to push to production or staging: name: Deploy to Production on: workflow_run: workflows: ["Auto-Release"] types: - completed jobs: deploy-to-production: uses: baumrock/RockMigrations/.github/workflows/deploy.yaml@main with: PATH: "/path/to/your/project" SSH_HOST: your-host.com SSH_USER: youruser SUBMODULES: true secrets: CI_TOKEN: ${{ secrets.YOUR_TOKEN }} SSH_KEY: ${{ secrets.YOUR_SSH_KEY }} KNOWN_HOSTS: ${{ secrets.YOUR_KNOWN_HOSTS }} I discussed whether having ssh_host + user in the workflow file is a good practise or not in a recent php meetup. It seems to be fine from a security perspective but it's preferable to use variables from a devops view, because you can then simply change variables or paths and deployments will still work. When changing paths in the worflow file anybody working on a feature branch that has an old version will get an error on deployment!

Hey @gebeer that was the problem... Your linked action was not the problem, the other one was 😉 I forgot to add the link to the new docs that I also added: https://www.baumrock.com/en/processwire/modules/rockmigrations/docs/releases/ In the new release file you see the action that I changed: https://github.com/baumrock/RockMigrations/blob/73f23de4e22b807d08e2d315ef7dc8bcc067e269/.github/workflows/auto-release.yml#L28 No. That's not correct. The new Auto-Release action is only for automated releases. The deployment didn't change!

Unfortunately it was not as easy as changing the version number. I had to find another workflow as the one used was archived and not maintained any more. But I have now added a dedicated auto-release workflow file to RockMigations which anybody can use to create fully automated releases (without nodejs deprecation notices) 😎 name: Auto-Release on: push: branches: - main jobs: auto-release: uses: baumrock/RockMigrations/.github/workflows/auto-release.yml@main secrets: token: ${{ secrets.GITHUB_TOKEN }}

Hey @Craig thank you for your purchase! 🤗 Please download RockGrid v1.0.2 and let me know if that fixes the issue! https://www.baumrock.com/en/releases/rockgrid/

Thx @gebeer I've seen that warning for a long time but didn't find the time to look into it yet. I'm not sure I understand this thread though?! What are you suggesting? Do you have a solution or was this just a report?

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 🙂