bernhard

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?

Hey @FireWire thx for testing RockCalendar and thx for your feedback and questions! Thx! I'll have to test and then push it to the repo. Just have two launches this week 😅🤞 Looks like a bug! I'll have to investigate next week! Correct. I disagree on this one. I don't think it's possible to get what you are describing without losing many of the features/flexibility that RockCalendar offers (like moving a single event out of the row, having custom fields for each recurring event, etc). BUT: I understand that this is an important need. My solution/idea was to just delete all recurring instances and then recreate them. That was before we had support for custom fields on events, though. So this might be a culprit. I also thought about maybe supporting a "move all", so when one recurring instance was moved it would ask "also move all following instances?" and then it would get the time difference of the move and apply that to all following instances. But when I did tests in that direction I even found bugs in google calendar, which tells a lot... Well... They could always pay someone (you/me) to get it done. But even then this might mean that this might have a side effect somewhere else, for example what about an event that has been pulled out of the series? Would that have to be modified or not? Maybe there would need to be a GUI for that, which asks the user what to do in such a case. But, well, that would be a lot of work, which means a lot of Dollars/Euros. So don't get me wrong. I'm not against it, I just don't have a good solution for it so far and I can't think of one. If you can please let me know and we'll see how we can make it possible! But at the same time I want to mention that Recurme had huge issues with how it stored it's data (as far as I can remember from what I read in the thread). I really don't want to make that module bad - just want to say that it might be a good idea that my module works differently and I'll be very careful about changing that 🙂

It would be great to have an API for keyboard shortcuts that is used across the admin and that can be used by module developers in the same way, something like ProcessWire.on('keydown.cmd+s', ...); ProcessWire.on('keydown.esc', ...); Even greater with support for javascript hooks. And maybe some kind of attribute click magic: <div> 1.2.3.4 <a href pw-click-copy='parent' title='Click to copy IP address to clipboard' uk-tooltip > <i class='fa fa-clone'></i> </a> </div> Early stage ideas but these would have been helpful for many of my modules for sure. Edit: Maybe instead of callbacks we could have attribute notation for keyboard shortcuts as well? <button type="submit" pw-keydown="cmd+s"> Save </button>

Hey @FireWire great thank you! I see some blocks that seem to be regular fontawesome 4 icon buttons, like the one with the map or with the calendar. You are aware that you can use any fontawesome icon for the buttons via the "icon" property of the block? Or are your blocks different?

Great 🙂 Thx for letting me know and I hope you enjoy the journey from now on!

See https://processwire.com/blog/posts/pw-3.0.179/ I think you only need to install the Less module then it should work. Modifying files in /wire is not a good idea as you will lose your changes on the next core update!

Sounds strange. Lacking any better ideas/explanations why this could happen, the first thing that I'd try is to install one of the default/blank profiles without any other modules and see if the behaviour is the same. If it is, then you likely have a problem with your server setup. If it works, the problem is probably in one of your modules or templates 🙂 Or maybe before doing that check from different computers or also different networks to narrow down the issue.

@neophron sent me his project and I fixed it for him. Maybe this is helpful for others as well: If you get an error message like this, please read the instructions and also check the trace of the request. It will tell you WHERE the call happened that caused the error: Aw shucks… Error: Exception: This feature has been removed with version 5 - please see upgrade guide at baumrock.com/rf-upgrade5 (in site/modules/RockFrontend/RockFrontend.module.php line 2794) #0 site/templates/_init.php (9): RockFrontend->styles() ... In this case it shows us that we have a call to RockFrontend's style() method on line 9 of _init.php! So I basically removed that and it worked.

That's just regular HTML/CSS stuff. Inspect the backend page where your textarea is. Get the name of the textarea, then add something like this in admin.less: textarea[name^="your_textarea_field_name"] { // for debugging to make it obvious that this code is active border: 5px solid red; // force a monospace font font-family: monospace; } The ^= selector makes sure that it will also work for repeaters, where your name would be something like your_field_repeater123

If you already have a python script that should be quite easy to do with the help of AI In PW just create a textarea field and make sure to let it use a monospace font so that you can properly paste/write your lyrics. (you can do that in /site/templates/admin.less) Then just grab that content and use your PHP method/function that your AI wrote for you and generate the html that you output on the frontend. PS: Nice idea also by @diogo 🙂

Awesome, thank you! This works perfectly and I have never allowed images in RTE fields, so I'm safe here 🙂 Thx for the note! I have added this as a tweak to RockAdminTweaks: https://github.com/baumrock/RockAdminTweaks/blob/dev/tweaks/General/RemoveVariations/RemoveVariations.php

This seems to be a fundamental feature so I must be missing something... I have a RockPageBuilder element called "Gallery". I don't think that it matters or RockPageBuilder has anything to do with it, but maybe I'm wrong, so I mention it for completeness. In that gallery block the client can upload images and in my code I create thumbnails from that images and show a gallery like this: Images are output like this: $images->eq(0)->maxSize(800,800)->webp->url Today the client contacted me, that she cropped one image, but the image does not update on the website... I thought I forget the cache busting timestamp, but that's in place and not the issue. Looking into the variations of the image I clearly see the issue: Image #0 and #2 are the newly cropped images. All others are outdated. Any idea why ProcessWire does not recreate those variations? I have done some research and found one old issue by myself that has been closed by @netcarver and I found this module by @Robin S But I'm wondering... am I missing something obvious? Why would I need an additional module to make sure that ProcessWire resets image variations when the underlying original image has been cropped? That makes no sense to me? Thank you very much for your help!

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.