aComAdi

Hi Adrian, 4.26.35 did seem to have resoved this issue. Tested it on one of the affected sites successfully. Thanks a lot for the very fast turnaround.

OK. So it's not solved per se. I reopened the ticket. When we create new sites for existing clients, we usually install those in a subfolder, e.g.: /new2024/ So far this has never been a problem. But it seems with Tracy v4.26.34 we can now not run the console commands anymore, because it will load the existing site in the root folder. I tried renaming index.html in the root folder, but then I just get a 404 error. Is there a setting in config or Tracy settings which I can use to ensure, the commands are run from the subfolder (/new2024/), where Processwire lives?

Never mind. After looking at the instances where it happens from a different light, we have figured it out. It's redirects in the root of the site. The sites all have preceeding brand selection sites. My bad.

Hi, We use RockMigrations (an older version) to run migrations for our various modules on client sites. We execute the migrations using the Tracy Console, which works for nearly 100 websites. However, intermittently, we encounter a problem when attempting to run scripts in the console. Instead of executing the script, the console either loads the front-end of the website into the output panel or, in one case, even opens the front-end in the current browser window, causing us to leave the CMS. We have attempted to identify the issue: It does not appear to be server-related, as some of these sites run on our own shared server with identical settings (Fast-CGI, PHP 7.3 or 7.4). It does not seem to be related to the ProcessWire version (3.0.240). We have disabled finished.php, init.php, and ready.php with no change. It does not seem to be related to the config files of ProcessWire (which can differ in structure between various versions). We have disabled markup regions to rule them out. We have completely deleted Tracy and reinstalled it. Tracy settings are 'standard', i.e., out of the box. This issue has occurred on installations where the console previously worked, but after an update (both ProcessWire and Tracy), it stopped working. Tracy: 4.26.34 PW: 3.0.240 Notably, on the affected sites, this issue occurs even when running no script (i.e., it’s not the script causing the problem). Could you please provide guidance or a solution to resolve this issue? Thank you for your assistance. Is there any setting that we are missing? Or what else could be the cause of this behavior? It keeps us from updating our moduls, we have to update them manually respectively. Any help/tip is appreciated.

OK. After upgrading to the latest version of PW I managed to make it work by adding the namespace to each tempalte. But this still seems strange, as we have an identical installation which works fine without having to add the pw namespace manually to tempaltes.

Thanks. In the _main.php template that should not be a possibility. But considering nothing else is working, I added the namespace to the template. No change. I also upgraded PW to 3.0.235. But still no luck. Any other ideas how to resolve this.

I just checked server settings and changed the PHP version from 7.4 to 7.3 to match the working installation. Without any success.

Hi, We have been using string translations in our sites for a while. Usually without much of a problem. I did notice an inconsistency before in that sometimes we would have to use _("string") and at other times __("string"). Event though they were the same template (in other installations). Now we have an installation, where no configuration works: __("string") Error in front-end Call to undefined function __(), did you mean _()? _("string") In this case the translation is not detected. No error in front-end $this->_("string") Translation is detected in the back-end Front-End does not display the translation Here some example codes. From a working installation: <p><span id="fzgVB"></span> <?php echo __("von"); ?> <span id="fzgTotal"></span> </p> From the broken installation with the above issues: <p><span id="fzgVB"></span> <?php echo $this->_("von"); ?> <span id="fzgTotal"></span> </p> This is the translation file: { "file": "site\/templates\/webKitLagerAuto.php", "textdomain": "site--templates--webkitlagerauto-php", "translations": { "99fa307ec57145b928f70f1bf9a6b0f9": { "text": "de" }, "399a817877af458537114697dbdcd1ec": { "text": "Trier par :" }, "f85a094911f1791512a9c6c340af8501": { "text": "Les v\u00e9hicules sont charg\u00e9s :" }, "ceab854bab8563c4c37d5411abf61119": { "text": "Rechercher un v\u00e9hicule" }, "17a1115519a7d611cea6663f039fc617": { "text": "Tous les types de v\u00e9hicules" }, "05db64b63f46a0d66ebaf9b6c52640da": { "text": "Tous les types de v\u00e9hicules" }, "ca4c95edfc1cb0bb7834c03181db5db3": { "text": "Toutes les marques" }, "d14ce9b3f96539a2b0cddce3f3d10964": { "text": "Tous les mod\u00e8les" }, "7ba626b3662c671ae1649986cb0d2946": { "text": "Tous les types de carrosserie" }, "cd9454ac308cd2e6664aa6a05bf8ebe6": { "text": "Tous les carburants" }, "2f43b4b9f99a34adbbc4c2dce12bdbf0": { "text": "Toutes les ann\u00e9es" }, "3551dcebb592af19007be6dccbe904cb": { "text": "Tous les entra\u00eenements" }, "02355d02162809861896c8c313d038cb": { "text": "Tous les engrenages" }, "4474fbc0115b236a45eb9573889b2653": { "text": "Rechercher" } } } Noteworthy: We use markup regions and this installation is ProcessWire 3.0.229. $config->useMarkupRegions = true; $config->appendTemplateFile = '_main.php'; In a different template, where the subtemplate is loaded with required_once(), this works: <h3><?php echo __("Kontaktinformationen"); ?></h3> https://www.autowag.ch/neu2024/fr/contact/ I am thoroughly confused.

Oh sorry, only saw now that this was within the Tracy branch. Upgraded Tracy to 4.25.13. That resolved the error output by Tracy. (But not my original issue that I was researching.)

I'll upgrade to dev version 3.0.235 then...will report back.

HI Bernhard, Have you found some explanation/resolution to this issue. We just installed a 3.0.229 instance and have noticed the same error in Tracey. Simultaniously we see the following notice on pages (in the backend) which we have never seen persiting before. FieldtypeImage: Settings have not yet been committed. Please review the settings on this page and save once more (even if you do not change anything) to confirm you accept them. We obviously saved the page and also checked the template and all associated image fields. All seems normal. Actually editing the page works correctly as well, as does the front-end. It's just confusing and we don't want to run into problems down the road with this installation.

Bumping this thread. It's an issue that has been brought up by clients, especially those with larger site structures. Selecting a page in the PageField set to "Tree View" is no problem. However, on edits its hard to identify if the correct page has been selected or which page has been selected altogether. A suggest improvement would be: Field Option: Tree Open/Closed This would improve UX of the field significantly.

Next lockup with log panels disabled.

First report: Been working for an hour with Tracy on (iMac, Chrome Version 88.0.4324.192, PW 3.0.165, Tracy ). In my case it's not connected to images. At the time that the 'lockup' happened, I had both the backend and frontend open in the same browser. Reloaded a page (with almost no content whatsoever) to test something. Then the endless load started. No missing images on this page. Note, that I currently have three bd-dumps on this page: 1 array, two booleans.

No worries. We greatly appreciate Tracy. I will work on a client site over the weekend and test these variations.

I figured, I will post the update: Turns out the culprit is Tracey Debugger. Once turned off, this phenomenon does not happen anymore. Luckily we only need it during installation and development of new modules really. All editors are now working with Tracey off and the problem has disappeared.

Hi, Sorry for the late reply. First case of Corona in the company. All sorts of emergency actions necessary. I will check @dragan's suggestions. @flydev ??Relatively sure no NGINX involved in any of the incidences this occured. Will report back if I find anything.

Hi, I am aware that this is a very broad description of a problem - but that's because I could not narrow it down so far. I just wanted to see if others have made that exprience or if this is even a known issue. On a regular basis, when logged into Processwire, the CMS and the front-end becomes nonresponsive. What happens is usually: User works for a while logged into the CMS and has another tab open, where she previews changes At some point, during a refresh/load of a new page IN THE CMS, the site is in an endles loading loop. When this happens, reloading the page, klicks on menu items, nothing responds. Closing the tab and and reopening in the same browser again results in endless loading loop (and eventual time out). When this happens, the front-end also cannot be loaded anymore in that browser. It's noteworthy that: Opening the site in another browser works Logging into Processwire in another browser works This happens regularly across various setups: Different browsers (Chrome, Firefox - haven't seen on Safari yet, because that's usually the last one I use to keep edition after Chrome and Firefox are 'locked') Different servers Different PHP versions (most installs are on 7.2.) Different versions of PW. I had it on 3.0.128 up to 3.0.165 now. Having site in debug mode or not Having cache activate or not Common to the installations is usually: Tracey Debugger RepeaterMatrix Rockmigrations Has anybody experience this? I haven't had any complaints from the clients yet - but that doesn't mean it does not happen to them. Internally this does happen regularly. Almost during every longer work session. Thanks for any insight. Adrian

Sorry for late replay. It's solved now.

The error has disappeared, but the actual label is still displaying. ? https://www.garage-fischer.ch/kontakt/kontakt/

Hi Moritz, We would lek to start working with hCaptcha for our Processwire client sites using Form Builder. Ran into the following issue. Hiding the field label causes 500 Internal Error. I've attached the the error as a screenshot. The environment is: PW 3.0.123 Formbuilder 0.3.9 PHP Version 7.3.16 Not a biggie, but might be an issue on some implementations.

Perfect. Thanks Gideon.

Hi, I have a question regarding the pagination (MarkupPagerNav). I have it setup for a news page and it works fine (currently set to Limit 1 for testing): http://www.odermatt-luzern.ch/neu2020/neuigkeiten/ Question: Change URL segment It's a German language site. Therefore I would like the pager URL segment from page1, page2, page3, etc. to Seite1, Seite2, Seite3, etc. I didn't see this to be possible in the settings or the API. Can this be achieved? Thanks in advance for any tips and hints. Adrian

We use RockMigrations regularly for adding custom functionality, pages, templates and fields to new projects and update the existing sites modules. Works a treat.

I wiped the installation and started new. I am ending up at the same place. The RepeaterMatrix simply drops the fields of type Image. That's the setup with a different item, but essentially having the same process as the original post above. Just replace wk_inhalt_start_links_bild with wk_inhalt_bilder : Here I fill the fields successfully: And when I dump the RepeaterMatrix item in the front-end, it's missing the image fields (wk_inhalt_bilder, wkinhaltbilder): Starting to get desperate here.