donatas

I know, I wouldn't want this for a regular page. But I'm using this field for email content that is being sent and links have to be full absolute URLs to work - that's the issue. The field has to be user-friendly, I can't use raw html. It's edited quite often. I would even like to use the page selector in the pwlink plugin, but that the links should remain absolute.

I want to keep the full absolute local URLs inside my TinyMCE field (edit: I'm using it to send email content), but after saving they are all overwritten with relative paths to the existing pages (edit: and relative links don't work in emails) Example: https://domain.com/my-link/ becomes /my-link only. And I need the full https://domain... version. I think I had seen such option some time ago, but maybe I'm mistaken? "Link abstraction" doesn't seem to fix this. I've tried many options in the field configuration, but no luck. Any advice? For now I am adding the domain back while rendering output with a hook for this field, but I'd rather not.

Hi @da² PW shows no error log for the crash. But I looked into httpd Apache error_log file and get this after site errors out: I work locally on a Mac so it very much might be a bug on platform specific implementation, as I see "SwiftNative" mentioned in the log. Would be interesting to see if other Mac users are experiencing this or it's just a super specific issue on my end ?‍♂️

Thanks! Doing more exploration I narrowed it down further that the issue is caused by using PW translation functions inside your static function: _() and _n(). Removing these it can be used as a static function and doesn't cause the error. But I guess that defeats the whole point to have time strings translated...

Hi. Yes, your updated file version seems to be working fine for me, no error. I guess it is safe to update the module with it. Thank you for your time and a useful module!

Hi, I have tried all your recommended tests and it appears that FormValidation.php is the culprit file! Copying it from the 2.1.46 version to the newest one alone fixes the problem! ? Form.php - still error FrontendForms.module - still error Including form code in template file instead of include file - still error TracyDebugger throws no error at all - the server stops the response at all so it has no chance to print anything. Browser console Network tab shows error "NS_ERROR_NET_RESET" on Firefox and status as "(Failed)" on Chrome As I understand there might be a problem with use of static function secondsToReadable. Switching to the existing non-static secondsToReadableCopy fixes the issue. My PHP knowledge ends here to figure out the reason why ?

I tried with both the newest 2.1.54 version and 2.1.47 module versions with the old Form.php file from 2.1.46 and it doesn't seem to work - I still get no response from server after submit. The issue is in some other file.

Yes I do have TracyDebugger. Actually I went and tested all the older module versions between 2.1.46 and 2.1.54 - and the bug starts appearing on 2.1.47 version. 2.1.46 was the last version that worked for me. So probably the introduced ajax functionality code may be the reason? Although I test the form with AJAX functionality turned off.

Thank you. Sorry, but nothing changed - still getting the same result. Tried disabling JS file inclusion, Disabled AJAX, Tried the FrontendContact module - same result. What info would you need from me to track down this issue? For now I will continue using the older module version, but would be nice to have up to date version and keep up with newest module developments.

Hi @Juergen Thank you for your time. I have already tried to test it with a new clean PW installation and a clean fresh module install. I don't use any VPN I tried with different browsers (Chrome, Safari, Firefox) - all give something similar of a reply. (Safari: "Server unexpectedly dropped the connection"). No browser plugins seem to interfere (tried with no extensions at all). However it is all good on a shared hosting environment on my provider. Only on my local machine it gives this bug. Having in mind that older version of module works and newest doesn't - my conclusion would be that the introduced new code in the newer module version might have something to do with it. I am trying to narrow down what environment setup parts could be involved in this, but am a little lost for now. Can it be file execution permission issue? I'm developing (successfully multiple sites) on local httpd (installed via brew): httpd -v Server version: Apache/2.4.58 (Unix) Server built: Oct 16 2023 15:06:20 php -v PHP 8.2.11 (cli) (built: Sep 26 2023 11:11:58) (NTS) Copyright (c) The PHP Group Zend Engine v4.2.11, Copyright (c) Zend Technologies with Zend OPcache v8.2.11, Copyright (c), by Zend Technologies ProcessWire 3.0.229 Form code: <?php // site/templates/_form.php declare(strict_types=1); namespace ProcessWire; $form = new \FrontendForms\Form('myForm'); $name = new \FrontendForms\InputText('lastname'); $name->setLabel('Last Name'); $name->setRule('required'); $form->add($name); $button = new \FrontendForms\Button('submit'); $button->setAttribute('value', 'Send'); $form->add($button); if($form->isValid()){ print_r($form->getValues()); // do what you want } // render the form echo $form->render(); Form include code in home.php template: <?php namespace ProcessWire; ?> <div id="content"> <?php files()->includeOnce('_form');?> </div>

Hi. Is it just me, but the newer versions don't work for me. I have tried a fresh PW install, fresh FrontendForms install via PW module installation from directory. I used the most minimal form variant with one field and a submit button (but tried with more complex setups too) and I get a "ERR_EMPTY_RESPONSE" response when I submit. PHP is 8.2+, everything is working fine on PW side. I have used FrontendForms v2.1.46 before and it all worked fine. I copied older version module files to the same fresh PW install and it works. But the newest v2.1.54 is bugged. Both with AJAX and without it is failing on submit. Any idea what could be wrong?

Very glad to see this module featured and immediately had a use for it. However when using it with Combo field from ProFields module (processwire.com/store/pro-fields/combo/) with an image upload field - it throws an exception: Exception: Method ComboValue::getFile does not exist or is not callable in this context My guess is the Combo field uses it's own custom properties or methods for field data.

Thanks @wbmnfktr for a reply. There are no Textformatters enabled on this field. We are using a lot of modules, but to my understanding none of them should be interferring with URLs. Maybe PagePathHistory, but there are no URLs configured to redirect to the language setup page and it seems this module is working fine with what it does. The field configuration is nothing far away from a default setup, just some TinyMCE buttons and plugins are disabled. Probably I should try looking into TracyDebugger hook debugging output, in hopes to see who is performing the URL change?

Hi, I have a multilanguage site, and when I create a link in a rich-text multi-lang field with PWlink CKEditor plugin (not yet TinyMCE) it converts it to an "/admin/setup/languages/it/" URL after save instead of the original URL I set - like "/it/" (non-default language version of homepage). It looks like the PWlink is looking for the page name ("it") and finds it in the admin part of page tree and skips the homepage. Everything else with languages is working fine. Is it a bug? Was happening in PW 3.0.184, updated to 3.0.210 but still happening. Any idea how to fix it would be appreciated! Thanks!

I have a multi language set up that is working fine for couple of years. default = Italian en = English ... But recently noticed that if I add a link with CKEditors PWLink plugin (like with "Select page") in a rich text field on a non-default language to the language homepage: /en/ it converts it to the admin language management page link after saving and the links don't work for visitors (and Google indexing too): /en/admin/setup/languages/en/ Would seem like a bug, but maybe there are ways to hide the admin lang pages from the PWLink? The rich text field has "Link abstraction", ACF and HTML purifier ON, would not want to turn these off as the website is quite large with a lot of rich text content. Any ideas where to look to fix this?