bernhard

Great stuff Ryan! Maybe you want to link to this blog post on the module's readme? https://processwire.com/modules/inputfield-tiny-mce/ OK I'm through the post and there's lots of great informations in it! Thx a lot! I'm wondering if there is an easy way of making a field have a minimal setup? The default.json with its merge features looks great for regular text fields. But what I often need is to have text fields that only allow the user to add two things: add line breaks and make some words bold. That's useful for my page builder where I have blocks for a very specific purpose (like inserting a multiline headline). Is there an easy way to setup such a field without having to manually remove all defaults? Another thing: really great stuff with the css styling feature!! What I wondered here is how we could add multilingual labels for our editor styles? Maybe something like this? (sorry on mobile) /* en = Red paragraph */ /* de = Roter Absatz /*

Hi @Kiwi Chris I've added a config setting to prevent migrations if you don't want them to be triggered automatically: $config->noMigrate = true; https://github.com/baumrock/RockMigrations/#running-migrations For adding this setting only to your local dev setup see https://processwire.com/talk/topic/18719-maintain-separate-configs-for-livedev-like-a-boss/

Nothing is broken. It just means that you don't have the required Less module installed.

https://github.com/processwire/processwire-issues/issues/1633

@adrian don't you think that this should be part of the core? That's why I'd prefer a PR over some hooks that may break at some time (AOS is a good example for that).

Yes and no. I think the answer to what you mean is yes, but to be precise: The LESS module (https://github.com/ryancramerdesign/Less) got some updates some time ago that make RockLESS obsolete. I'll update RockLESS readme, thx!

Hey @ukyo thx, but you missed my point (sorry if that was not clear enough). Yes I've played around with it and like it but still haven't had the need to really add it to my toolset. I'm happy with https://doc.nette.org/en/forms and https://github.com/contributte/live-form-validation you can try that by trying to submit an empty contact form on https://www.autohaus-bendel.at/ My question was not about how to implement forms in general. I know how to do that and I've already built a module for that similar to @Juergen's FrontendForms module. It was about the submission process only since I did not find any good instructions on that part even though it's a very important one! Your answer and your video kinda proves that as it's also stopping exactly at the spot where it get's interesting ? I'll update the post title!

Thx!! I really like that approach, it absolutely makes sense to me ?

Forms are a pain. They are not only quite complex to build from a technical point of view but also from a UI/UX perspective. I've done some research and surprisingly I was not able to find helpful information on one crucial part of forms: Form submission! All blog posts and videos (like this one https://youtu.be/hPS7LUW7SlA) show all the necessary steps to make the form+fields look good and behave well, but none of the posts that I found showed anything about form submission. How do you handle that? Or do you have any information about that topic for me? I mean... There's so many ways how you can tackle that and I'm still not 100% happy with the way I implement forms with my forms module. There are two main ways of submitting forms: Regular HTTP get request AJAX AJAX are maybe a little harder to implement but have the benefit that they don't need another page load. Regular form submissions need to show a success message though and that has often been a challenge for me to implement that in an appealing way. Most of the time I show a success message instead of the form and add an anchor to jump directly to the success message if the page should be longer. On AJAX submitted forms on the other hand it is easy to show a modal (submitting form.... done, success!) but then you have the question what to do with the form that was submitted in the background? On one project I've made all fields disabled after submission so that the form is still there and takes up the same place as before (to not get any layout shifts/quirks) but it is obvious that it can't be submitted again (and the submission has worked). Does anybody have better ideas?

Ping @Jan Romero maybe something for Christmas? ?

Thx to a PR by @wbmnfktr everybody using Twig can now use {{ dump($var) }} ? https://github.com/baumrock/RockFrontend/pull/14

@wbmnfktr that might be related to the topic you postet lately?

Hey guys could you please help me: Why would one detect mobile/desktop on the server side? Isn't that a thing for the frontend and with ProCache you can't use tools that rely on PHP. So could you please share some background? Thx ?

Maybe a mutagen issue? Do you have mutagen enabled? Did you try stopping (or even deleting) the ddev project and then starting it again?

I'd find it more intuitive to use these labels: But it could use the same code as yours ?

Maybe @teppo can mention that signup form in pw weekly? My guess is that the mention of RockFrontend in pw weekly was responsible for most of the traffic I got on that video and why it performed a lot better than the following videos.

I think the main thing is that you have to build all the CRUD stuff and GUI on your own which is just ready to be used in PW. File upload? Just add a files/images field. In Laravel it seems you have to do that kind of things on your own. Everytime. Or am I missing something?

I understand nice and clean but I'm not sure what you mean by "short" - the video I linked is a 4 hour course ?

I've had a conversion with @3fingers over the last few days regarding that topic. I contacted him via PM because I am planning something similar and I did not want to give the impression that I was torpedoing his plan (or that he spends much time that in the end does not pay off because there is a similar free course by someone else). To be more specific, what I have had in my mind for quite some time now is to make a ProcessWire version of this video: ProcessWire from Scratch 2022 | Laravel Alternative? (on processwire.rocks) I thought that might be a good idea for several reasons: While watching that video to get an impression of laravel I thought so many times: "That would be so much easier in PW", so I wanted to show that to others I thought such a video could maybe catch brad's attention and he might be willing to share the video across his audience or even try PW and make a video about it himself I thought it's a good starter project with a good structure that shows a lot of the most important concepts and it would be nice to have a side-by-side comparison @3fingers asked me to post this publicly to get some feedback from the community so that we can then decide how we should proceed so that everybody benefits from it.

I can't remember for sure but I don't think so. I think it has always been injected automatically (as it was meant to be zero-setup from the very beginning) and I wanted to avoid having instructions in my readme that are necessary to make everything work. Is your problem fixed now?

I've had a look into the module's settings and both fields that download to or modify the /site folder clearly state that ? So if one is using the module on a multisite installation that does not use the /site folder he/she should be clear about what RockFrontend will do and if that is a good idea for his/her installation. But I'll add a note in the readme.

Is Alfred.js somehow loaded before RockFrontend is defined? It should be loaded after that of course. I don't think that is a problem. If no Alfred tag is on the page, then also Alfred.js is not loaded and therefore there should not be an error. Are you maybe loading Alfred.js manually?

Hey @gornycreative thx for that find. I don't really like the word "hardcoded" here, because RockFrontend is actually using smart paths where /site/... is not really a hardcoded path and would also work on installations in a subfolder like /foo/site/... But obviously I did not think of multisite environments ? Maybe it would be enough to do a str_replace in the path here? https://github.com/baumrock/RockFrontend/blob/825caa131e7bca6e988f34e0bbb6d4cd17e33e15/RockFrontend.module.php#L690 Above that line you could add this: $path = str_replace( $this->wire->config->paths->root."site/", $this->wire->config->paths->site, $path ); Maybe that already works? Having to replace all occurrences of /site with $config->paths->site would also be an option, but I'm not sure if I like that. What is really nice with using /site/templates/... paths is that the IDE gives you hints of the available files and folders: That's the reason why I'm using that syntax all over ?

https://github.com/baumrock/RockFrontend/blob/825caa131e7bca6e988f34e0bbb6d4cd17e33e15/RockFrontend.module.php#L267

RockFrontend is injected via Hook on Page::render It looks like either that hook is not triggered or you are maybe using another hook that overwrites/replaces that hook?