Leaderboard

Hello @DrewPH Thanks for reporting this issue and you are absolutely right. I have changed all class names (not only the "block" class name) of the CAPTCHA element by adding the prefix "ffm" to all classes. Now it should be very unlikely to get class names conflicts in the future. So please update to the latest version 2.2.17 in order to get all changes. You can read the full changelog here. Important information to all other users: If you have modified the styling of the Slider Captcha by adding your own CSS by overwriting the default CSS, please take care that the class names have been changed now and your changes will no longer affect the the styling of the CAPTCHA. So please adapt your custom CSS with the new class names.

Ah! I get it now. I wouldn't mind sharing them but... there's a fair bit of abstraction on some of them. I'll probably share more when I can complete the project to have something cohesive.

That was unbelievably quick... thanks very much :-)

I've integrated Stripe Payment Elements with my system which we can discuss @bernhard. Stripe is hugely popular in the US and it's probably the easiest to work with.

Hey all! I've been creating new block/widget buttons for the current project I'm working on and wanted to share them in case they may be useful to others. They're SVGs intended to complement the style of buttons that come with RockPageBuilder. This post has been updated with a link to a Github repository containing all of the buttons currently available. New buttons have been added. Existing buttons have have been tweaked for quality and consistency. Download from or fork the Builder Buttons Github repository Rather than keep this post up to date with every button that is added, visit the Github repo to see the most current example and download/clone buttons for use in your projects. Buttons include: Accordion Announcement Articles Audio Bios Call To Action Card Over Image Code/Embed Events Image Image Carousel Image Mosaic Image Roll List Lists Products Reviews Video Weather Preview (not in order of list) If you find them useful, let me know what you think!

v1.4.1 is now fully translatable 😎 Every aspect of the module! You can translate day names, month names, set start day of the week, set labels of all buttons, etc.! Docs are also updated: https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/translations/

hi, looking at your dump, it sounds more like a htmlspecialchars encoding, you may either remove it from the field setting or use htmlspecialchars_decode on the output before json_decode 🙂 have a nice day

I'm trying this module out in a site I'm building, and it looks like being ideal. I appreciate you developing and supporting it. However, I've run up against a class naming conflict... In frontendforms.css, in the "Slider Captcha" section, there is .block { position: absolute; left: 0; top: 0; } This has instantly nuked my entire page layout, since I'm building the site with RepeaterMatrix fields and am using "block" as the main class for each matrix! I know I can use a different class name or override the attributes, but I'd like to suggest that modules should be as specific as possible in their CSS usage in order to avoid conflicts, especially with a word as generic as "block". Is it possible for you to use a wrapper class in the css file, so that other classes named "block" are not affected when this module is installed? Something like this: .sliderCaptcha .block { position: absolute; left: 0; top: 0; } Then, in AbstractSliderCapture.php, you could have something like this on line 48: return '<div class="sliderCaptcha" id="' . $formID . '-captcha" data-validated="false"></div>'; I may have missed something you'll need to change but I'm sure you get my point. Hope you can consider this - thanks!

Thank you @bernhard for your work!!!! This sounds very useful and I will try it out in the next time.

it was just the idea to share not only the images of blocks but also the .php and .less files of the blocks - and that this could be a thread of it's own anyone could post in their own solutions.

Yep, Stripe is easier because it has way much better documentation than PayPal. @bernhard You will probably get more help by checking out my PayPal module than looking at the PayPal documentation.

Interesting! Wouldn't hooking into PageFinder::find() work?

@bernhard Nice! Glad they made the cut 🙌

Latest find (and heavily on repeat) - and foundation for my new found love for Vaporwave and LoFi: EP-133 KO II Vinyl Sample Hip Hop Beat (Nina Simone record) Another nice and chill mix: Kater Carlo - TechHouse 08.2024 KaterCarlo A bit (way) more expressive but great for late night sessions: CLOUDY F2F KUKO

Yes, that's one of the reasons I chose them over Stripe 🙂 But for developers outside of the EU I think adding other providers should be simple enough, but that's just guessing at the moment. Maybe @Jonathan Lahijani can tell me more when we meet. Puh... that's a little tough question 😄 The short answer is: I think RockCommerce should be great for any kind of shop. The longer answer: RockCommerce is built in a way that it provides all the tools that you need to cover all the necessary steps that you need for e-commerce: Product pages Product pages add to cart button a cart a checkout BUT: These pages have to be built by the developer. So there will not be any predefined cart page, no predefined checkout, no predefined product layout. Nothing (on the frontend, of course!). Just the tools to make building that very easy and enjoyable. I think this is what @Sanyaissues and @gebeer meant when they said "the processwire way to do e-commerce" (what I nice statement, thank you!!!) So RockCommerce will get everything in place on the backend so that we as a developer can build the shop on the frontend the way we want. Using Bootstrap, using UIkit, using TailwindCSS, whatever. Easy Example: This is all you need to display items that are in the cart: <template x-for='item in items'> <div><!-- x-for must have one root element! --> <h3 x-text='item.title'></h3> <div>Amount: <span x-text='item.amount'></span></div> <div>Variation: <span x-text='item.variation'></span></div> </div> </template> And this is all you need to add a product to the cart: <a @click.prevent="addToCart">Add To Cart</a> Want to show the cart count anywhere on your page? <div rc-cart-count>0</div> And you can customize that 100% to your needs - just keep the AlpineJS attributes like "x-text" or @click and you'll be fine 😎 So why is that related to your question? It's still some work and that work has to be done and that work has to be paid, after all. So there might be a "break even" in terms of project size or budget. But from a technical point of view I don't think that there are shops that are too small for RockCommerce or that are too big. RockCommerce should scale with your needs just like ProcessWire does. But the number of products? Should not really matter, if you know how to deal with that number on the frontend. Sales volume per year? Well... Your work to implement it and the RockCommerce one-time license fee has to be covered, that's it. There will be limitations in terms of features, of course. For example coupon codes are not implemented yet (but it's built to support them) and there is no inventory management at the moment (though you could add a textfield to every product that shows something like "available within 1-3 days / 1 week / sold-out "). I think for smaller shops this can be a great opportunity, because you can create extremely light weight and efficient, well integrated processes. No bloated shop interface with 100 distracting informations or popups or slowly loading pages. You only add what you really need. The ProcessWire way 🙂 At least that's what I try! 😇

This just reminded me of the classic Volkswagen 2.4-liter diesel AAB engine they used in their Transporter vans. It was probably one of the few engines, like the one above, you could fix with a hammer, a few liters of thick oil, and loud swearing.

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 😎

Hi @bernhard, I really like to work with RockFrontend (and RockPageBuilder)! Now I have some questions resp. want to make sure what would be the best practice: I am using the autoload-layout feature and am loading a _layout.latte file. But I also would want to make some template specific modifications, like having an element on the startpage, which is not included on all the other pages. I can add this element in home.php, but then it will be included before the opening <html>-tag. When I put the elements into home.latte, this file won't be output until I add the {do $rockfrontend->noLayoutFile = true} directive to it. But if I add this line, the home.latte will of course override my _layout.latte, which is also not what I want. So I added the following to my _layout.latte: ... {* only on the startpage *} {if $page->id==1} {include "src/latte/partials/custom-element.latte"} {/if} </body> </html> - Is this currently a recommended way to e.g. have a custom element on the startpage? - I noticed that content in home.php will always be added to the output, while home.latte will only be added, when using {do $rockfrontend->noLayoutFile = true} in it. Is it possible to load home.latte while preserving _layout.latte, too? - Is RockFrontend compatible with ProcessWire's MarkupRegions? => I removed _main.latte and am now rendering the template-specific latte-files "manually". With "echo" in the respective template PHP-files, and using a _output.php, ProcessWire's markup regions work. But I think one cannot use both techniques, _main.latte and Markup Regions, at the same time. Also, _rockfrontend.php has to be deactivated.* - Currently the page in the docs regarding the render()-method is empty. https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/render/ - Is it possible to render any latte-file with render()? Then I could render home.latte within home.php ... but I would again need MarkupRegions to insert the rendered markup in the right place. I tried it, but with no luck so far. => RockFrontend's render() method can render any latte-file. The trick is to omit _main.latte and implement a more "traditional" approach, with a custom _output.php, in which the Markup Regions are put together.* Maybe you have any clues ... and what method would you use to insert template specific markup while using a global _layout.latte template? * Of course, the purpose of RockFrontend is not to only use the render()-method, so I recommend to not use Markup Regions and use the full feature set of RockFrontend instead. Also, it could be that I have overlooked something, so this information may be subject to change. Edit: Answered some of the questions

This week there’s new $pages->saveFields() and $page->saveFields() methods on the core dev branch. You might already be familiar with the $pages->saveField($page, $field); method which lets you save one field from a page, or $page->save($field); which does the same. This is useful when you only need to save one field from a page, rather than the entire page. Now we have a plural version of that method, which lets you specify multiple fields on a page to save: $pages->saveFields($page, [ 'title', 'body', 'summary' ]); Below is the same thing, but on a $page object, so you don't need to specify a $page argument: $page->saveFields([ 'title', 'body', 'summary' ]); You can also use a string if you prefer: $page->saveFields('title,body,summary'); In my case, I needed this method for a project I'm working on, and I also needed it to save without updating the 'modified' time or user, which you can achieve by specifying the 'quiet' argument. Though note, the 'quiet' argument is available for all the page saving methods and has been around a long time. But I'm not sure how widely used it is, so I'll mention it. $page->saveFields('title,body,summary', [ 'quiet' => true ]); This week the API methods for Select Options fields have also been updated to add more convenience for getting, adding and removing options to an existing selection. Let's say we have an Options field of checkboxes named "colors". Each selectable option has an ID, optional value, and title. Now you can get, add, or remove by any of those properties. Previously you had to work directly with SelectableOption instances, which wasn't as convenient. // add by title of option 'Blue' $page->colors->addByTitle('Blue'); // remove the option with value 'orange' from colors field $page->colors->removeByValue('orange'); // get SelectableOption instance of option with title 'Red' $red = $page->colors->getByTitle('Red'); echo "ID, value, title: $red->id, $red->value, $red->title"; // check if colors has an option with value 'purple' if($page->colors->hasValue('purple')) { // it has purple } The methods added to SelectableOptionArray (not yet reflected in linked docs page) include: getByID($id) getByValue($value) getByTitle($title) addByID($id) addByValue($value) addByTitle($title) removeByID($id) removeByValue($value) removeByTitle($title) That's all for this week. There likely won't be any core updates next week, as I'll be out of town again. Thanks for reading and I hope that you all have a great weekend and great week ahead.