bernhard

If I'm not missing something it should be easy: The ajax request will return data in the language that the request was sent to. A request to example.com/whatever would return english A request to example.com/de/was-auch-immer would return german You just have to make sure to send the request to the correct endpoint.

It still feels crazy that we can talk to computers now, but it has already had a huge impact on my life. Not only my dev life. It's also still crazy to call given results an "idea", but I guess we don't have better words for it so far... If you liked the experience try https://www.cursor.com/ or https://windsurf.com/. I started with cursor, then gave windsurf a try for some weeks. I switched back to cursor, because cursor tab so so extremely well at predicting what I want to do next, that I feel it makes me extremely faster all the time while I'm working. Windsurf on the other hand felt better when asking it to create files, read the codebase, have a chat or use it for non-dev questions (like a web search or some other crazy tasks). While both are already next level compared to copy-pasting things to chatgpt, because they know "everything" about your codebase, I think cursor tab is a different beast. It's there for you all the time. You just type three letters and it predicts 3 lines of code. It's incredible powerful in my opinion and it's also great and fun to learn. Because sometimes it predicts new patterns and then you can look that pattern up and if it's a good pattern to know and use you can keep it in your mind and start using it on your own. If you use AI only actively when asking specific questions you miss out on this.

I'm not sure in which cases specifically, but the menu sometimes needs a cookie/cache reset as well. I'm always using Tracy Debugger for that:

Ok I just had that exact need and realised that once you realise it's too late to add a hook, because it will not work for the past, only for future logins ^^ So I support this request 😄 And similar to what @nbcommunication wrote it might be helpful to have two different timestamps: one for the last manual login (done by a real user), one for the last API login (via code like forceLogin() or such)

Hi @hellerdruck, how do you suggest I help with an issue that I cannot reproduce?

It is a solution, yes. A good solution? I don't think so. The problem that you are talking about is why I built RockMigrations. ProcessWire makes building all kinds of inputs/apps/guis/relations relatively simple. The drawback is that all these setups that are created via user input (and not via code) are one-off solutions. That means they only work once for this specific project. If you want to make them reusable you have two options: Create a site profile (with all its drawbacks, as mentioned above) Create code that does all the setup that you usually do by hand Option 2 is usually a LOT of work. That's where RockMigrations shines. Instead of building everything with your mouse you build everything with migration files. Once you know how to use it is is not a lot slower. In fact I think if you take the whole picture into account it is a lot faster (think of reverting changes, refactoring, deploying, testing, etc). That was some background. Back to your situation: You can use the site profile on a subdomain. If you need date from the other system you can use bootstrapping or use multi-instance features of PW. It might be easy. It might not. What you can also do is install the site profile and then move things over to your new site step by step.

@hansv I don't think that it is possible to use site profiles on existing sites. That's the problem with site profiles compared to modules. Modules can be installed on any website at any time. Site profiles are a starting point to get a new site up and running quickly and to have 100% freedom of what happens after that. That means site profiles have the benefit that you are not locked to the module approach. You can build whatever you want explicitly for your use case. A module on the other hand is always something that many projects might share and therefore all features that you add will also be added to any projects that the module is installed in.

Is your problem now solved? Did you try to run migrations again? Either with a modules refresh or via CLI? I think that should have solved it. That does not really comfort me 🙈 But it's also extremely hard to say what could be the reason for what you've seen...

Ok sorry for triple-posting, but I don't want that you miss that: What I'm usually doing is to pull the production state via "rockshell db:pull production" before I commit anything and push it to production. That way you should have the exact same state on local as you have after deploying to production. You have the DB state of production and the file state of development, just like you'd have if you push all new files to production. So in theory that should make sure that all migrations etc. run exactly the same as after a deployment to remote!

This makes me wonder... Maybe you have some kind of migration there that messes things up... Maybe something kicks in too early and then the regular process does not fire.

Hey @gebeer this is not normal. On development you click on the plus to create a new block. The module will then create the files for your new block (eg /site/templates/RockPageBuilder/blocks/Whatever/Whatever.php and the existence of that file will make RockPageBuilder create all necessary templates for that block via RockMigrations on the next page load. When deploying to production the existence of that file should be enough to create the template for your block.

Please have a look at this thread. As far as I know this is still valid:

You can also take a look at https://www.cursor.com/ and https://windsurf.com/editor - I tried both for several months and both are very good and have their pros and cons.

Either way it should not log something on each request. The goal is that RockMigrations does not slow down the site and only does something when it really needs to do something. This was obviously not the case here even though a single fileputcontents() might not be a noticeable penalty, but still...

Hey @FireWire thx for the report! This was partly intended and partly not. The intentional part was that it SHOULD log something if migrations are triggered but disabled (to make it obvious if somebody expects migrations to do something and nothing happens). What was also intentional is that the file does only reset when migrations actually run. The idea was to save disk read/write operations. What was NOT intentional though is that this logging took place on every single request, which obviously means a small performance penalty on each request when using RockMigrations - even when it is disabled. I just pushed a fix for this to v6.8.2 https://github.com/baumrock/RockMigrations/commit/429ce68f3418aeedee108d80949fc14a224561a5 Now the logging only happens when $config->debug is enabled. I also removed the log regarding MagicPages, which was logging on every single request, adding an additional file write on every single request 😮 Thank you for making me aware of that!

Ever needed a color picker on some kind of settings page? Didn't want to install and setup a full-blown colorpicker module? Here's a quick and dirty hook to change a regular text field into an <input type="color"> type of input: Before: After: <?php public function init(): void { wire()->addHookBefore('Inputfield::render', $this, 'changeFieldType'); } public function changeFieldType(HookEvent $event): void { $f = $event->object; $colorFields = [ Site::field_col_primary, Site::field_col_secondary, Site::field_contrast_primary, Site::field_contrast_secondary, ]; if (!in_array($f->name, $colorFields)) return; $f->attr('type', 'color'); } So right before the text input is rendered we change its "type" property to "color" and the browser will render a default color picker 😎 It once more shows how versatile ProcessWire is. And maybe it helps someone... 🙂 PS: Be advised that with that hack you only modify the optics of the field. The field will under the hood still be a regular text field, which means you'll not get any sanitisation or such from it and you might have to take care of that on your own. In my case it's a superuser-only settings page. So it is no issue at all.

Thank you very much @FireWire This also fixed this issue and is now part of RockPageBuilder v6.5.0 😎 I'm really thankful that you are not only using my modules but also helping to improve them 🙂

Hey @noodles this is now possible with the latest update v1.7.0 😎 I worked on that for several hours - far more than I initially thought. I tried different things, refactored, reset, and settled with a new "expert" option to keep the "simple" and "advanced" modes as they were and not bloat the GUI for something that probably 99% of users will never need?

When using vanilla JS you need to make sure that this header is set. This is what tells PW it's an ajax request. jQuery sets it by default, vanilla JS doesn't.

Ok then it means you are missing the ProcessWire namespace on the _init file 😉 I've added a note to the docs, thx.

Hi @Stefanowitsch the module needs to be installed otherwise the rockdevtools() function will not be available

Hi @bia welcome to the forum, ProcessWire will not output anything automatically. It will only output what you tell it to. Usually that is HTML (websites), but you could also use it to output PDFs or an API or whatever. You tell it what to output in so called template files. So for the template "events" it would call /site/templates/events.php, for example. In that template file, you would then place something like this to show children of your events page: <ul> <?php foreach($page->children as $event) { echo "<li>{$event->title}</li>"; } ?> </ul> This would output an unordered list (<ul>) of events. Then you could add links to directly view those event pages: echo "<li><a href='{$event->url}'>{$event->title}</a></li>";

I like both suggestions a lot 🙂 So a final question would be where to show it if all language tabs are expanded. I'd probably hide it then?

Looking at that mockup again I was a little confused... I think it should better say "clear content in all languages" ?

Ok great we have some positive feedback from ryan as well. He'd be willing to improve that detail in the core as well: Didn't think about the page render option before... What do you guys think? At first I thought it might be exactly one would need, but it might also be exactly the opposite. Maybe someone wants to have the default value blank, but other language values non-blank. Didn't have a good example for that, but I think I have one: What if we are on a website that shows events taking place in Vienna. The default language of the website is german. So for the german version of the website it's just showing the event title and details. But for the non-german website it might show "this event will be in german". Ok thinking about it further I'd probably add a select field then on each event to choose the language and then add that logic to the template code. Anyhow. Wanted to mention that and wanted to provide ryan with some good suggestions that he can easily add to the core. Happy about your input