bernhard

Hey @Bia welcome to the forum. I might be wrong but to me it sounds like you still have a wrong assumption what ProcessWire is and how it works. ProcessWire is a development tool to build websites or anything similar. You can not only build websites with it but also intranet applications, backends for single page applications, etc... That means whoever built your website did it THEIR way. Nobody else can know how the website that you are looking at works under the hood. That means if you really want/need to change anything on your website there is a 99% chance that you need to change some code for this. That also means you need access to the files of your website. That also means that you might need to understand how your website is deployed to the server. Your developer might have just copied all files to your server. But he/she might have setup an automated deployment pipeline. It also means that it would be wise to first test all your changes locally before you push them to production. Otherwise you risk to break your site and then it might be down until someone can fix it. If you don't have someone for that at hand you risk to have a very bad time with some very uncomfortable questions 😉 But of course it also depends on the type of website you are working on. If it's not important and does not have lot of traffic this might not be a big deal... Who knows. I think in your situation it would be the best to find someone experienced to have a look at your project for maybe an hour or two that can explain to you how everything works, how it is setup and what to expect in terms of future maintenance or development and hosting. I'm not talking about how it works in detail but to get the big picture. Then you can decide how to proceed. If you want me to do that you can write me a PM or request a meeting at https://www.baumrock.com/en/contact/. There are probably cheaper options though. You can also ask for help in the jobs board or, of course you can always ask questions in the forum. It's a friendly community and answers are free, but while usually you don't wait long for answers it would probably not be the quickest way in your case. Having said all the above to answer your question: If that form is built in code you'd have to open an IDE and search for the term "Culoare:" or "Colored" or "White" in your codebase. Then you might find the file that is responsible for the dropdown. If you don't find anything in code then it means that your developer used some kind of form builder and the data is stored in the database, not in code. Hope that helps 🙂

*NOT 🤣

Hey @HMCB the module does not offer a plug&play calendar for the frontend. Every frontend is different. Every project has different needs. One might need a month view, another project might need a list view or a weekly schedule... All these needs have been solved by libraries like https://fullcalendar.io/docs/initialize-globals so there is no need or justification for RockCalendar to reinvent the wheel. The cost/benefit calculation would clearly be negative here. But for everything behind the scenes (the backend) we have a common ground (the PW admin interface), so there you can save a lot of time and effort with RockCalendar. RockCalendar should provide all the necessary helpers though to make implementing any calendar (for example one might prefer the toast ui calendar https://ui.toast.com/tui-calendar) as easy as it can get. If you are missing anything let me know and I'll try to add it.

Yeah, that's definitely on the Roadmap, but I have other priorities at the moment.

I think you should also be able to send other field's data to MailerLite: https://github.com/baumrock/RockLite/blob/ce0e818cf4b7f9e5ef4cf6a0ee1244f6c291ab92/API.php#L44-L51

I've read several times that slow page loads came from lots of pages being loaded into memory when loading the page. This might be due to a poorly configured page reference field (eg a selectbox with thousands of pages) or maybe another module with a totally different purpose. I think you are right that an autocomplete field should not cause any issues. I'd try to look into the debug tools first and see how many pages are loaded on that initial iframe request. You should see that in the bottom right corner if debug mode is on.

I'm not sure, but I think so and that might be a good thing to add. Can you try to modify the rock.php file. There I catch any exceptions and only write the ->getMessage() output to the console. If you remove the try/catch, do you get more helpful output?

Hey @Jonathan Lahijani what you provide to me might be even more vague than what RockShell provided to you 😉 So I don't have any idea so far. What is your exception that you see? What is that one line that you get from RockShell?

I don't think it's very elegant, but it works ^^ I think you can also use the GUI and click on "use one of the existing blocks" after clicking on the plus to create a new block, no?

Hi @FireWire to "clone" or "mirror" a block it just needs an empty (!) php file with the same name. /site/templates/RockPageBuilder/blocks/Foo/Foo.php (all code) /site/templates/RockPageBuilder/blocks2/Foo/Foo.php (empty)

+1 Docs in markdown have been working great for me. All my module docs are markdown, so they are part of the repo (could be another repo as well, as images for example bloat the module code, which is not ideal). I'm using RockFrontend's dom tools to enhance the markdown docs with some special features. That makes it possible to have working forms on my docs for RockForms, for example: https://www.baumrock.com/en/processwire/modules/rockforms/docs/ ## Working Example In this example we will build the following form. [rockforms=Quickstart] Or another example is rendering code blocks and showing copy buttons. In markdown it's just a plain code example, on the HTML page it's an interactive element with nice labels etc: ## Example This example shows how you can make every required field's label bold and add the note `optional` to every field that is not required. Note that NetteForms uses the terms `label` and `caption` for field labels. [rockforms=Optional] `label: /site/ready.php` ```php $wire->addHookBefore( "RockForms::renderField", function (HookEvent $event) { // get the field that is rendered // in netteforms its called "control" $control = $event->arguments(1); // make required fields bold if ($control->isRequired()) { $control->getLabelPrototype()->addClass('uk-text-bold'); } // add optional note if not required else { $renderer = $event->arguments(0); $label = $control->label->getText() . " <small>(optional)</small>"; $control->setCaption($renderer->html($label)); } } ); ```

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...