bernhard

Hey @Cybermano glad it was helpful! That's what I've been using before I had the idea of hooking into WireMail::send. Everything in life has pro's and con's... So I'd not say it's a bad practise. But what I like about the solution is that it fits my credo "simple things should be simple". Sending a beautiful thing should be simple. And what you show might look QUITE simple it's not as simple as my version. If you only have one mail it won't matter or your version would even be easier (because you see everything that is going on). But if you are sending mails from different places in different occasions (eg on registration, on a new post, on a schedule, etc...) then my version keeps your code DRY (don't repeat yourself) whereas your version either tempts the dev to copy and paste those lines of code or be too lazy and just send out an ugly 90s style email. Both is not ideal in my opinion and investing a little more time to setup the hook will be beneficial in the long run. Also, while it's just a few lines of code, when your codebase grows every line of code that is not instantly and easily understandable matters. Your brain has to read the code, understand it, interpret it and remember it. With your str_replace that might be QUITE easy, but things add up and suddenly it might make the difference between easy to read code and a bloat of spaghetti code. It's about building a habit. Another problem with your solution is that if you copy&paste this to 3 spots, for example, and later you add another replacement tag, you have to do a search&replace and you might miss one spot and you introduce a bug. If you have it on a central place this can not happen. On the other hand if you want to render different files or you want different tags for different emails your approach might be the better one. And for someone not familiar with your codebase it might be easier to understand your version vs. the hook, because only seeing the $mail->send() somewhat hides how the mail gets sent with nice HTML and your version makes that obvious.

Thx! I think your fix should be fine and at least did not cause any problems on my end. I've pushed it to v6.3.1

Hey @Stefanowitsch thx for the quick meeting. I updated the docs in the hope that others won't have the same problem of understanding how the toolbar works. Let me know if the docs are still missing anything.

There is a long open issue for UIkit to support CSS variables but unfortunately there seem to be no efforts in that direction: https://github.com/uikit/uikit/issues/4534

First you need to make sure to get the value of the page reference field as PageArray (not a single page object or such). This might depend on your setting of the field and whether output formatting is turned on or off (in the hook it should be off, but just in case...). As ->removeAll() works it should be a PageArray in your case. In my case the field is called "pagelink" and I force the return type to be a pagearray via [] Then from the pagearray you can remove your page via remove("id=...") which is all you need I think

Not sure but a quick shot: use ->removeAll();

I think the concept of /site/ready.php has been there well before I started using PW in 2013 - so I think you can just create it and it should work. Your issue sounds strange though and I'm not sure what would be best to do. But I'd try to see if it works with force-login and then resetting the superuser password. At least that will show you where the problem lies (either a wrong passwort or something else).

Thank you for all your work on this great module!

Hey @teppo no I didn't dig deeper to be honest 😇 But your buffering note makes sense and when working with SSE on RockCalendar with DDEV I think it worked without any strpad or such!

Do you have the same userAuthSalt in config.php? If you change that (or it does not exist) you'll not be able to use the same password. You can also reset/force-login like this: https://processwire.com/talk/topic/29593-solved-do-the-reset-password-tricks-work-for-you-they-dont-work-for-me/?do=findComment&comment=239355 But it would be better if you understand why it does not work and then fix it if needed 🙂

Hmm. That's strange. Your error states that it fails with creating the discounts page. So my guess is that this issue was introduced with the discounts update at v1.1.0 - May I ask you to try v1.0.0? Strange is that I was able to reproduce your issue with v1.1.0 but 1.1.1 fixed it for me. So I'm not sure how to reproduce/fix it but the first step would be to confirm that 1.0.0 works for you. You could then also try to update to 1.1.0, which should work. That's not a solution yet but it might help to narrow down the issue! Thx for your help and sorry for the trouble!!

Hey @bramwolf thx for the detailed request (and of course thx for your purchase 🙂 )! Thx! This was very helpful! I think I have fixed the issue - could you please try v1.1.1? https://www.baumrock.com/releases/rockcommerce/ Sorry for the trouble! Please let me know if everything works now as expected and mark the topic [solved] if it does 🙂

Hey @neophron RockFrontend doesn't change the _main.php file. I guess you mean the RockFrontend Site Profile?! Whatever. As I told you at the very beginning you need to remove all styles() and scripts() calls and add assets manually. How you do that is up to you. You can either add the script/style tags manually to your main markup file or you can use RockDevTools. It's really up to you. But unless you remove all styles() and script() calls your system will not work and is not expected to work. There might be some inconsistencies with the site profile or other references to that old concept. I'm sorry for that and I'm trying my best to remove all those outdated informations. For that it would help to get the exact steps you took to get where you are. I understand that this might be frustrating, but please also understand that it is frustrating for me to try to help but don't get proper information and searching in the dark for issues that I don't see. What is that status on your end? Did you get it working already? What did you try to make it work? I'm very busy until end of next week so it would be nice to get an as detailed report as possible. Alternatively I can offer you that you send me your project and I set everything up so that it works.

Great! It was actually a very little change so I was quite confident it should work as expected 🙂 Problems with multilanguage websites and PagePaths module: I am happy to provide my dirty code, if you'd like so. 😉 I'll look into this when I find time, but I have to launch a project next week myself 😅 My plan for the RRule is to add another option to the GUI: I thought about adding "Simple / Advanced / Expert" - but not sure yet. Maybe just adding all possible options (like in the link above) to the "advanced" tab would be better? I think keeping the very basic "simple" option and a full blown "advanced" gui should be fine from a user perspective...

Hey @FireWire and @noodles I have a present for you: v1.6.0 now supports custom fields/values for recurring events. All you have to do is to add the field you your events' template and then tell RockCalendar to "keep" it: wire()->addHookAfter('RockCalendar::keepFields', function ($event) { $fields = $event->return; $fields[] = 'booked'; $event->return = $fields; }); See the full docs here: https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/recurring/#custom-fields-for-recurring-events

Hey @noodles Glad to hear that! 🙂 I've added that quote to the RockCalendar page on my website: https://www.baumrock.com/processwire/module/rockcalendar/ hope that's fine? I'm not sure I fully understand. Fields are hidden because the idea is to inherit all fields except the date from the main event. That concept might be extended in the future - for example it might be necessary to show basic information for all events in a series but some details specific to a single event (like a weekly podcast with a general description and then an individual subject for each recurring item). But in your case I don't understand where they want to enable/disable the event? Do you want to disable the main event and then disable/hide all events of the series? Or only one? I don't get it please be more precise with your description. Thx!

Thx! It was great 🤩 That's very good news, so we'll get it working! I'll let you know when I have the new version ready. Cool. Let me know when exactly and we'll arrange something! 🙂

Hey @noodles thx a lot for your purchase and for your kind words 🤗 And thx a lot for looking into this on your own! I'm on vacation and I'll be back at my computer at Thursday - I'll take a look into your issue then. If you find anything useful until then please let me know. Are you able to create this schedule on https://jkbrzt.github.io/rrule/ ? Personally I hate these kind of dirty solutions so I'm happy to work on a better solution but it needs to be a solution that helps everybody. Otherwise we might want to find a way to make it work for you and also work for everybody else (aka make something hookable or such...).

Not sure I understand your message. RockDevTools does not provide a UI. It provides an API to minify/merge assets and it provides SSE based live reload for your local pw development.

It worked for me. It would be nice to provide more information for me. What did you do, what did you expect, what was the actual behaviour? Or if you know what needs to be changed to make it work out of the box please provide that information.

Hey @spoetnik I just pushed an update to the rockfrontend site profile. Can you confirm things are now working and showing infos as expected?

Hey @neophron thx for the update. You have old ->styles() and ->scripts() calls in that file that you have to remove. I tried to explain what to do and the reason for the breaking change as good as I can here: https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/asset-tools/ I'm also updating the rockfrontend site profile that you can use for inspiration. Does that help?

Well... the pragmatic, most efficient and probably best solution would be to use DDEV. Other than that it might be that LiveReload breaks in subfolder installations. I have to check that. But still I can't recommend DDEV enough for PW development.

Thx 🙂 Glad if it is helpful! Yeah that's possible. Unfortunately I had to change the way how I manage assets in my frontend. Thx for the report! I'll try to fix those issues asap.

Hey @neophron sorry for the trouble. But no reason to be desperate - I'm here to help and this one will be quite easy to fix 🙂 Background: Unfortunately I had to introduce a breaking change with how assets are managed and injected. In the old version I relied on RockFrontend's styles() and scripts() methods to inject styles/scripts into the frontend. The new version leaves that up to the user. This means he/she has more control over their final frontend markup (no automatically injected styles and scripts) but it also means more to do during the initial setup. Can you share your _init.php please? Especially around line 9. PM if you don't want to share it here.