bernhard

Hey @FireWire This is what I had written so far: But then things didn't work the way I planned 🙈 I invested several hours in your reports this week. Managing existing recurrences is really not that easy, unfortunately. I even encountered an error with google calendar again while testing this week. Initially I thought I'd add this and have some great content for my monthly newsletter... But here we are. 3rd of April and no newsletter yet... I'm working on the RRule issue though and hopefully have some news soon!

Ah, thx, just replied on that pm and didn't see this message. Please try the version that I sent you and let me know if that fixes it. If not we'll have to find another solution.

It looks like your autoload module is not autoloading 😉 Maybe you changed the "autoload" prop to true after installing the module? Then you need a modules refresh to make sure ProcessWire recognises that change and loads your module on every request. Just set "forceIsLocal" of tracy to true and you'll have tracydebugger enabled even for guest users. This is what I'm using in all my projects in my config-local.php: // tracy config for ddev development $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, 'localRootPath' => getenv("TRACY_LOCALROOTPATH"), 'numLogEntries' => 100, // for RockMigrations 'editor' => 'windsurf://file/%file:%line', ];

Ah sorry didn't see you are trying it from within a module. The hook that I shared should work there as well. Your module needs to be an autoload module. So I'd do this: add my hook in /site/templates/admin.php and check if it works add my hook in /site/templates/ready.php - it should work as well add my hook in your module's init() method - it should work as well If it doesn't work place a " bd('fired') " or whatever in your module's init() method and check if that dump shows up on the login screen. If not, then your init() is not triggered on that pageload.

It depends on where exactly. Or what exactly you want to modify. All backend requests call /site/templates/admin.php, so you can do something like this there (BEFORE the final require statement): wire()->addHookAfter('ProcessLogin::execute', function ($event) { $event->return = 'before' . $event->return . 'after'; }); edit: oh, and you can add scripts/styles there as well: $url = rockfrontend()->url(__DIR__ . '/admin.js', true); wire()->config->scripts->add($url); /** @var Config $config */ require($config->paths->core . "admin.php");

Thx @Stefanowitsch I understand. I've just added that to v6.4.0 Docs are on the module config screen:

Can you send me your invoice number / mail address via PM please?

I'm not using SCSS so I din't think of that. But it would not be hard to do I guess. Why would that help? Isn't it just creating a new file? Or should it have some prepopulated code?

@Jochen Fritsch the current version is v6.3.1, can you confirm you are talking about v5.2.0 which is from 02/2024? https://www.baumrock.com/en/releases/rockpagebuilder/ ProcessWire 3.0.229 is also not the recent version. So are you talking about an old project that has been working before or is that a new install? You might watch out for errors in the console and you might hit a max_input_vars limit on pages that have many many blocks/items/fields. One huge advantage of editing blocks on the frontend is that it will only ever load one block with a hand full of fields. On the backend all fields have to be loaded, which might cause issues (though I never hit any limit myself).

Do you have v1.4.1 ? This issue has been fixed 2 days ago: https://github.com/baumrock/RockDevTools/issues/3

Great, yeah sounds like a good solution. The title field is often special with its global flag so this is very good to have as a reference, thx for sharing!

Hi @snck thx for the report. Can not think of any. Could you please try to reproduce this issue on a fresh installation and then provide the exact steps to reproduce it? Thx!

Hey @FireWire would it be possible for you to create a short screencast or tutorial how to use penpot to create a simple buttom from one of the source files of rockpagebuilder? I just signed up but I'm a bit lost. And using the existing ones with affinity publisher somehow it messed up stroke widths...

I'm almost always configuring my templates to automatically update the page name based on the title 😉 Yeah, nice! But still, my point is to make it more obvious to the user to not forget to translate. I always test these things with my mother and this is eye-opening from time to time! 😄 She can not type blindly. So she types, then looks up on the screen. I bet a lot that she would not realise the change from "translate to all languages" to "clear all languages" after she typed or hit backspace. I updated my post with some new screenshots of mockups. I like it because it would be obvious but it would also cause the UI to jump around because it moves the input down. I tried to avoid that with where I placed the ui elements.

Thx. No offence. Just tried to say no hurry from my side for a solution. Thx for considering it seriously. My guess is that Many don't provide feedback Many didn't even realise If they did, they didn't think of accusing the UI for it but thought, "oh, I need to remember next time to wipe all fields" Just guesses, of course. In my project we have a multisite setup where we clone one site and then change the content afterwards. This might have made the issue more obvious, but I think it does not mean that it's not an issue on regular sites. Another detail why it popped up now is that the client was doing all the content editing on her own. If I had been the one to edit the site, the issue might have never popped up, because I would have thought (3) from above. The reason why I reported it as issue is because my project will hopefully be used by other clients as well and every detail matters, because when done wrong it either means bad results on the frontend (content showing up on a different language that should not be there) or more support from my side. True, but I really don't see a problem here. My main point is to make the user not forget to wipe the translations as well. On a single-language field it's totally fine to just delete the content and save. Same as above: If the user thinks of it, no problem. But I doubt he/she does. I also thought that it might be good to have another indicator on the language tabs to show when they are filled while the default tab is empty. Maybe in red? Color blind people wouldn't be able to see it though. Maybe something like this: Field when empty: Field when filled in all languages and the default language gets cleared out: Non-default language tab with an empty default language tab: Or maybe a bit more compact using a tooltip: It's a tabler trash icon which looks a bit different than the regular fontawesome trash icon anywhere else in the admin: <svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24"><!-- Icon from Tabler Icons by Paweł Kuna - https://github.com/tabler/tabler-icons/blob/master/LICENSE --><path fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 7h16M5 7l1 12a2 2 0 0 0 2 2h8a2 2 0 0 0 2-2l1-12M9 7V4a1 1 0 0 1 1-1h4a1 1 0 0 1 1 1v3m-5 5l4 4m0-4l-4 4"/></svg> The orange warning could pop up whenever the main language value is cleared out. Then the user can decide to either enter the new field value and hit "translate to all". In that case the warning would also be beneficial as it reminds the user of hitting "translate to all" after entering the new text as well. win win hit "clear content for non-default languages" PS: I think it should probably be a core feature... PPS: I think it would also be good to remind the user of translating the content if he/she entered/changed the content of the main language. Something like this: Ok now I realise that the user might also want to change the main language and then wipe all other languages, so the "clear content of non-default languages" should maybe appear whenever the main language was changed (either to empty or something else) and any other language is not empty

Hi @bramwolf that's great! Great you found the reason for the issue. The multisite module is a dinosaur and has not seen any updates in 7 years. Of course in the ProcessWire universe this does not have to mean anything and soma for sure knew what he was doing, but I tried the module several times and always got into trouble somewhere. Rewriting page paths is a huge change and 3rd party modules (like RockCommerce) might need to account for such situations (or the other way round). So to be clear hear, I'm not going to even try to officially support the usage of RockCommerce together with any unofficial multisite module. I have written my own RockMultisite module and I'll likely never share it with the public because there are too many possible pitfalls. Having said that, of course I do try to help you and if there is anything I can do to make it work for you without breaking anything for anybody else I'm happy to do that! But unfortunately I don't understand what you are trying to say here: --- Thx for that question. I was totally thinking that I mentioned that in the video, but turns out that I had the RockCalendar module in my mind. See this section of the showcase video: https://youtu.be/40h6I4i8JKs?si=rTlUzI95f8tH4dNr&t=254 This is exactly the same case/reason for RockCommerce and this shows why it's a separate module. Because I need the features/UI for multiple other modules. It seems that this information was missing for RockCommerce and I'm sorry for that. I updated the docs here: https://www.baumrock.com/en/processwire/modules/rockcommerce/docs/product-variations/ If you have any further questions let me know.

Hm. Really appreciate your work on this! Thank you very much. But as much as I understand and agree with this: I really don't think that it is intuitive for users to look for the "wipe all" at the opposite direction of the button that does the same thing when filling fields ("translate to all"). My point is: We all understand the necessity of deleting all fields. And we might think of it when we need to reset a field. But the average user? Do you really think he/she will clear the text field, then head over to the translation icon, then click clear all? I think what will happen is that he/she clears the field (deletes "Home" in your screenshot), hit's save and doesn't even think of deleting it in other languages. Maybe if he/she does, then I think it's more likely that he/she will look for it where he/she always looks for it. Below the field where it says "translate to all". In our project that's what everybody really got used to. Fill in the field, hit translate, hit save. I honestly and strongly think that the "delete all" feature/button should be close to the "translate all" button. I get your point about a cluttered UI, but what if a button to "delete all" only appeared if one of the non-default languages are filled and the default language get's cleared out? It would not clutter the UI, it would appear as the user clears the default language value and it would probably remind the user to also clear the other language's values. What I could also think of is something like this: Here I'd see the challenge to differentiate between users that case where someone wants to only delete this languages value or all languages values. Another idea would be to instead of this: Show a popup as soon as the default language value gets deleted that shows something like: "Delete the content of all other languages as well? Cancel / OK" Please don't hurry with a solution and take your time 🙂 I think a big part of making this feature as useful as possible is not only about providing a way to do it but also about showing/reminding the user that going this way might be necessary (to not end up with orphaned content).

How would a "clear all" button would be in the way of anybody? I really think that this is a must have feature. My client said so too. Would be interesting to hear other opinions, but for me I vote for enabled by default 🙂

Yeah I was a bit surprised and almost already asking, but also was too busy with other stuff 🙂 That would be great! I was kind of expecting that it was intentional, but at the same time it is really a pain if you want to wipe content from a multilang field, especially if you have more languages (as you need several mouse actions for each language when all you want is to clear the field). Also I can see that it might not be obvious to some that to clear the field in all languages one would have to clear the field in one language and then hit "translate to all". So I think an additional button would be a great ui improvement. But I'm wondering... how would ProcessWire handle that without fluency. Wouldn't that either be a core improvement than an additional feature of Fluency?

Hey @millipedia congrats. I understand that but it's not as easy as it may sound. I'd either have to add RockFrontend as a dependency then or have several features duplicated across both modules that I need to support... Or I'd have to extract it to yet another module and add that as a dependency for both RockFrontend and RockAjaxWhatever... Neither option is better than having it in RockFrontend and working on making its footprint as small as possible so that even if you just use a fraction of what the module has to offer it will still be safe, stable and fast. Any help in that direction will happily be merged (but don't know of any performance penalties when using the module).

Nice, thx for the explanation! Sounds like a cool project!

Nice! But why would anyone want to download the same file with 3 different names?? 😅

Hey @elabx thx for joining! Yes, but using named arguments it should not matter, so using "recursive: false" should set the "$recursive" parameter (which is the third) and the second should default to null either way. But something is not working as it should in my opinion, so something is wrong either in my head or in the core ^^ PS: Here are the links to the methods in the core: Pages::___clone = https://github.com/processwire/processwire/blob/44fcf13ea2d7f14a04eed54c29afcc79eb46ec45/wire/core/Pages.php#L1047 PagesEditor::_clone = https://github.com/processwire/processwire/blob/44fcf13ea2d7f14a04eed54c29afcc79eb46ec45/wire/core/PagesEditor.php#L1324

Today I used this: $clone = wire()->pages->clone($p, recursive: false); And I wondered why it was still cloning my page "$p" recursively with all its children... Then I tried this: $clone = wire()->pages->clone($p, null, false); Which worked as expected. I looked into the code but was not able to find an explanation. AI was also not helpful in this case. Any ideas?

I can only repeat myself. Thank you for that great module! Today we had the case that the client removed text from a textarea in the native language. When checking the other languages I found that there was still some text there, which we didn't want. So I clicked "edit this block" and then on the empty german textarea I clicked "translate to all languages" in the hopes that it wiped the content of all other languages as well. But it didn't. So I had to clear all fields manually. Is that intentional? Not a big deal for sure, but I can't think of a use case where clicking on "translate to all" on an empty field should prevent also deleting the other languages values?