bernhard

Hey @Stefanowitsch another update 😍 RockCalendar v1.2.0 is now translated to German (and Finnish, if AI did a good job 😄 ) https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/translations/ If you find anything that is not translated yet please let me know!

Hey @Juergen writing the docs for RockLanguage I did some research and found this old thread. I guess you were facing the challenge to ship your module with translations? Anybody facing the same problem please have a look at RockLanguage! All you have to do is add language mappings (eg german=DE) and then add a folder /RockLanguage/DE to your module. RockLanguage will then copy all translation .json files from /site/assets/files/.../...json to your module. And not only that. Once you translate a new string via the PW backend, RockLanguage will automatically copy the new json to your module's folder so you can just commit it to github 😎

Just pushed v1.1.1 which fixes an interesting bug that @Stefanowitsch sent me via video that showed up when multiple checkboxes have been checked (eg on weekdays mo+tu+we...). Interestingly it only happened when MO was selected together with other days. The reason was that my reactive GUI unintentionally updated the "value" attribute of the first checkbox whenever other checkboxes have been checked. So the value of the first checkbox was not "mo" but "mo,tu" or "mo,tu,we" etc. 😄 That's now fixed and the value of the "mo" checkbox stays "mo" whatever other checkboxes are selected or not 😎

Ah! Now I get it 🙂 That makes a lot of sense. I'll try to come up with something useful as soon as possible, thx 🙂

Yeah but I don't understand what you mean by "same order as they are appearing in the layout". Because clients can rearrange blocks and then there is no unified sort order?!

What do you mean exactly? 🙂

Thank you very much @FireWire I've added them to the repo and they will be part of the next release ❤️

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.