dragan

Is that your actual code? There's a missing > there $config->urls->root vs. $config->urls-root https://cheatsheet.processwire.com/config/urls/config-urls-root/ If that was just a typo here in the forum post, you might wanna check Docker-related forum posts, e.g. https://processwire.com/talk/topic/10736-running-a-processwire-site-with-docker/

It works perfectly fine if you just put the code inside a template. I guess using such functions as wireSendFile() inside Tracy aren't meant to work exactly the same (or not at all) as when you are viewing a PW page in the frontend. (I used an image file for testing instead of PDF, but that doesn't matter)

What version do you need? I can see ancient releases @ https://github.com/icecoder/ICEcoder/releases?after=v2.2 ... way back to v.0.5.9 https://github.com/icecoder/ICEcoder/releases/tag/v0.5.9 (2012)

Glad you have found a solution. It would be nice if you could share it here, so that other community members who have the same question in the future, will benefit from it. I guess you used a hook in the end?

Do you mean Form Builder?

I'm old enough to actually remember Macromedia Adobe Flash... sometimes you were forced to use that plugin just to display a (dynamic) custom font (sIFR). Oh the fun we had... sometimes I think the young generation of web developers don't know how lucky they are. 😃 </derail>

$this->addHookAfter('ProcessPageAdd::buildForm', function ($event) { $form = $event->return; // If adding page under particular parent if ($this->input->parent_id === '1041') { // Add inputfield to form after existing title field // If you name the inputfield the same as the field you want to populate // then the entered value will be saved automatically $f = $this->modules->InputfieldText; $f->name = 'myfieldname'; $f->label = 'My Field Label'; $f->description = 'my field description'; $f->required = true; $f->attr('required', 1); // use HTML required attribute too $title_field = $form->getChildByName('title'); $title_field->label = 'Page Title'; $title_field->description = "page title description"; $form->insertAfter($f, $title_field); $event->return = $form; } }); I got this code a long time ago from somebody in this forum, and it works nicely. I can't find the original thread right now. It basically renders the field "myfieldname" in the first screen when you create a new page under parent id 1041. Not sure if that helps for your scenario.

Well, it's certainly a sign that something's wrong somewhere. I never quite encountered the same problems (either separately or in combination, i.e. empty FB iFrame + can't delete modules). Things I would try / look at: Maybe your hosting company changed / updated something? (PHP version? .htaccess settings) Install Tracy Debugger and put your PW site into "debug mode" (in site/config.php). At the very least, you'll get some warnings / errors that you normally wouldn't see. Check server logs as well as PW logs See if there's any suspicious stuff in your browser JS console. Copy everything to the local machine and see how everything behaves there. Hopefully somebody else with more Form Builder experience will soon join in with help/tips.

You might wanna clear the cache. (site/assets/cache/) __() seems to be a multi-language string somewhere, that is not being recognized. If that really comes from the core FB files or your own templates, I can't really tell.

Well, there are several forum threads where similar issues were discussed. (storing user-prefs with sessions / cookies) https://processwire.com/talk/topic/21244-solved-redirect-based-browser-language-permission-to-change-language/ https://processwire.com/talk/topic/8733-autodetect-language/

It looks like you have a textformatter enabled for file descriptions. Try to de-activate that HTML purifier textformatter.

As if Corona wasn't enough, this morning Zagreb was hit by an earthquake. It seems that several hospitals were also damaged. Now instead of staying at home, several people are forced to go outside.

No, I'm just genuinely surprised you didn't hear about that tool before, that's all. It's been around for quite a while. And yes, it works great. If you're doing frontend work the whole day, it's a great time-saver.

You really only discovered this today? We're using it since years (with Gulp, Babel, Webpack etc.). Welcome to the 21st century 🙂

@mjut Please don't place your question in more than one place. I read both of your posts, but I'm still not sure about the whole scenario. Please define what "even if I previously did chose Danish" actually means. Where and how did that choice happen? Did you create a link that stores language preference in a cookie or session? In your other post, you mentioned that visitors are coming to your site via QR codes. If you want people to see your Danish language content, then simply use your Danish language URL for the QR code, not the default one. There are many different strategies how to tackle such things, e.g. detect the user's browser default language and (if necessary) do a redirect. Or make the user click somewhere and store his/her preference in a cookie or session. From a usability point of view, you would create your landing page in a way that the users can quickly and intuitively switch language versions, if needed. The default PW multilang site profile has a nice commented working example (how to dynamically switch languages). Bottomline: If you did your homework re: information architecture / UX, no special technical "trickery" is needed. Just make sure your navigation and everything else (breadcrumbs...) in your site setup takes ML into account, and once the visitor is on "his/her" language version, they know how to get their respective language content.