bernhard

Hey Frank, you are very vague with your information that you give us. Therefore it's not easy to help. If english is a problem for you just write your question in german on deepl.com/translator and copy paste the english version here. Which table? A database table? Or PW pages? Where is your date stored? In a regular PW field? Then it would be a simple $pages->find("your_date_field<..."); But we don't know anything about your setup, so nobody can really help.

You can use TextformatterRockDown for that. You can any custom tags you like.

Ok so ALFRED will stay in RockFrontend, thx for letting me know @gornycreative and @MarkE That's not intentional behaviour and I've never experienced something like this. If you provide instructions on a fresh installation with step by step guide to reproduce the issue I can have a look into it.

I'm aware of container queries being something coming in the future but I thought it's not there yet or at least not well enough supported to be used just now. Let me know if I'm wrong and I'm happy to add support for it if that's possible. I think rfGrow() is a great helper and I'm happy that it's useful for you as well ?

Ok then maybe Jumplinks hooks after pageview and so that track404 is called nonetheless. You could also hook after pageview and make sure that your hook has a very low priority to make sure it fires at the very end (after all other modules that might have hooks attached).

Great. Yeah that's the lowest hanging fruit I guess. Your concerns about my other suggestions make a lot of sense. And I'd not call the way it is "really annoying". It would just be the icing on the cake. But not if it makes things worse, of course, so please take your time to make a good decision - I was just throwing in ideas ? To the flip: Where that translation screen can be handy is the following. I'm working on my website which will be german as default and english as second language. Some texts have been in english originally because I was working with a non german designer on the website. Now I need to translate those sections into german, which is not possible with Fluency, because it doesn't allow translating from the second to the first language. I could also use the deepl website for it, but I'm using informal language (eg "Was willst du kaufen?" rather than "Was wollen Sie kaufen?") and the online translator of deepl does not allow me to select that informal version ? I'd have to pay, so it's better to either translate it myself or rewrite the translation after copying. In Fluency I can select the less formal version and I get the correct translation instantly ?

Another one that would boost my workflow: Guess what I want to do... Translate it to english ? But that needs two clicks, one on "english" and one on "translate". Why not show all available languages right beside "Translation Available"? I guess that's the case 99% of the time - you enter text in the default language and want to translate it to other languages. What about something like this? Translation Rready | Translate to: EN, ES, GR or to all languages I know it's a very small thing, but for me when working with RockPageBuilder I have Text usually split into many blocks, so that means a lot of clicks for translating blocks and if I could half that amount that would be very welcome ? PS: A problem with that approach would be that you don't see the result of the translation whereas with how it is now you instantly see the result because you are on the right tab. Maybe it could jump to the tab after translation? Not sure how that would work for the "all languages" though, but I guess it would still be nicer to click "translate to all" and then click through all the tabs to check the result rather than clicking every language and translating it one by one...

Hey @FireWire another little suggestion: The config shows two languages for this site, but when opening the translator it shows this: This site has only two languages and when using the translator it's most likely because I want to translate something from German to English or vice versa. It would be great if "translate to" had "English (British)" preselected. And it would be great to add a little button between those fields to flip them. Similar to route calculation services where you can flip route from a --> b with a single click to b --> a Thx again for this really awesome module.

Recent versions of RockMigrations also show you all the settings and their possible values once the module is installed just by hovering over the setting. I'd recommend using this technique rather than copying all the code. Most of the time that is easier and you don't end up with messy migration code...

It seems to be a common misconception that if you start using RockMigration there is no way back and you need to use RockMigrations for everything. That's not the case.

RockMigrations has a lot more to offer. It has a proven workflow for professional and automated deployments for example and it comes with MagicPages that have a lot of great helpers if you are using custom page classes. It has helpers to make working with the page editor easier (eg the wrapFields() method) and it has helpers to quickly see all the properties you need via mouse hover. Even if I died tomorrow you could just continue using RockMigrations for the next 10 years. If anything is not supported, just go with the regular API. If anything breaks with future updates, just remove RockMigrations from the project and that's it. From that time on you could rely on core api and just remove old code (if that's even necessary). But there's nothing bad in using the core api if you prefer. It's just too cumbersome for me.

You can either provide the shortcut (works for DE and FI) or the full url to the zip file

Why don't you just put line 14-19 into /site/migrate.php ? Then you can run "php site/modules/RockMigrations/migrate.php"

Hey @Clarity it seems you have something else going on, because the error says that headers already sent with some output... Could you please provide a step by step instruction with the blank site profile that lets me reproduce the issue?

Same here, as explained in the issue on github. The issue should be fixed already on the dev branch!

In almost 10 years I think I have never waited more than a day to get great answers here on the forum ?

@ngrmm what you say is correct and it's very easy to PREVENT publishing of unpublished pages. But if I'm reading correctly @mpdude requested a process where an EXISTING (aka published) page can be edited by a user, but the CHANGE to that page is not published until a more privileged user approves that change, but with the original page staying unchanged and published throughout the whole change request process. I don't have experience with the ProDrafts module but it sounds like a good candidate ? Alternatively you could implement a custom logic like this: user clicks on "change request". you use the PW api to clone that page (that's really easy) and you save it under eg /drafts. you save a reference to the original page, eg via $newpage->meta('originalpage', $oldpage->id) you send an email to an admin that a new change request was created (easy using WireMail). you add a button "approve" to that page. once that button is clicked, you loop over all fields of that page and save that content to the original page (using the page meta reference). after that you can delete the draft page and you have all the changes on your original page. That way you can quite easily build very custom workflows that exactly fit your clients needs.

Great update, thx @FireWire ! Another small thing to improve the UX: Hovering the translation icon shows the help on hover after some time. If you add "uk-tooltip" to that element you'll get an instant tooltip on hover styled by uikit: That's really a small thing but still a little nicer I think. Another one, maybe more helpful: When clicking that icon you end up on the translation modal. There you need to select the language from the I thought it might make sense to suggest the installed languages here, but that might not be so easy, as they might be named differently than in deepl (eg Deutsch vs German) But I found another hardcoded color ?

Hi @Clarity I'm always using this snippet: <?php // install german language pack for the default language // this will install language support, download the ZIP and install it $rm->setLanguageTranslations('DE'); $rm->installModule('LanguageSupportFields'); $rm->installModule('LanguageSupportPageNames'); $rm->installModule('LanguageTabs'); $rm->setFieldData('title', ['type' => 'textLanguage']); I do that once and then comment everything out so that it does not run on every migration. Once I have the files in the project I simply git push them to live.

Ah, sorry, that might have been a property that PW sets itself later in the process. Didn't know that as I'm using file modification timestamps as stated. Sorry for the confusion, but maybe good to see that one has to be careful with what you name your properties ? That's one of the downsides of allowing these kind of dynamic things I guess...

This has been the case until we got Url Hooks in 03/2021 ? ? PS: Also have a look here:

Yeah PW is very open here and PHP has been too. Since PHP 8.2 those dynamic properties are deprecated: https://php.watch/versions/8.2/dynamic-properties-deprecated

Just tried and it instantly worked with the code I shared above. I've added an example to the readme. Does that help? https://github.com/baumrock/Scss/blob/main/README.md

I think because there is nobody that cares about making it more popular. Which is a shame. And I think it's a little bit similar to linux. It's far more flexible, far more secure, but that also means that things are more complicated. There is no standard way of doing things and that's a problem. That means it's a lot harder to communicate and to learn. In windows or mac it's easy... Win10, 11... etc; MacBook Air / Pro ... Easy and everybody can understand that. Linux? Mint, Arch, Ubuntu, Suse etc etc... Which one to choose? Decide yourself. That's nice for someone who wants that freedom but it's a pain for 90% of "normal" users. So back to your question it's the same situation. There is no standard way of doing that in PW. You can (have to) find your own solution for it. It's easy. But there is no standard. I like to use timestamps of the file for cache busting. If you use RockFrontend that will be done automatically for you. If you want to read more about cache busting in the PW backend this issue has some interesting discussion: https://github.com/processwire/processwire-issues/issues/1791 And to give a simple solution to your actual question about where to put some constants: You could simply add that to config.php $config->version = "101"; And then append it to your assets like this: <link href="foo.css?v=<?= $config->version ?>" rel="stylesheet">