Leaderboard

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! 🎸 😎

@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/

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 😄

Hey Ivan, Sorry, looks like I've completely managed to miss this topic. Also, this could probably use a bit of an overhaul in Wireframe, and a docs page as well of course. This is indeed the default setup, and your guess is correct: "static" was initially borrowed from somewhere else (possibly some version of Zend Framework, or perhaps our old in-house CMS, but not sure anymore) and eventually replaced by "resources", which seemed to be more common term. assets/dist was added with the idea that this would be the location for built/generated versions. My current workflow actually places dist under resources as well — so there could be e.g. resources/scss/, resources/images/, resources/fonts/, and finally resources/dist/. Additionally I often have a resources/lib/ directory that contains "libraries", which may be third party dependencies that are not installed via yarn or npm, or site-/app-specific JavaScript classes etc. In my opinion this doesn't matter all that much, as long as there is a convention for placing said files, so that it doesn't change from project to project. Personally I would keep "resources", and place generated files in either resources/dist or assets/dist — latter part doesn't matter a whole lot, and as such I am now wondering if the whole assets/dist thing should just be discarded from Wireframe. Hope this helps explain things a bit at least 🙂 Technically I would like to have a "public" directory, but I'm not sure if that is really meaningful here: in the context of ProcessWire files are often accessed from other directories as well, so it is almost impossible to split the project into public and non-public parts in such a way. In something like the Sage theme for WordPress (at least slightly older versions, not sure of the current state) there were "resources" for source files and "public" that contained identical structure with built files — or copies in case of files that were not modified during the build process.

@bernhard Would love to chat about RockCommerce. I have my own internal ecommerce system that I've built with PW so I've walked this path as well and can offer some insights.

Thanks and nice to meet you both @gebeer and @bernhard! RockCommerce looks so promising, it really feels like the procceswire way to do e-commerce.

Thank you for updating the actions in both scripts!

No worries! If no one else has reported this issue, perhaps it's a host specific issue. It's pretty easy to set the plugin up, so not a big deal. Thanks for the fantastic plugin!

$image = $gallery_page->images->first()->size(540, 404, [ "cropping" => ['50%', '35%'], "quality" => 80, "focus" => false ])->webp->url; Maybe it is auto detecting a focus presset. Try disabling it.

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 @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/

Indeed, I do. And I'd be very interested to try your module

Nice thinking @bernhard! I have one config.php with reads a config.ini file using "parse_ini_file" which is one level up from /public/. No passwords in my Version Control and the same config file for all installs.