aComAdi

JFTR: I did wipe the installation and re-installed with dev version 252 (instead of 253). With 252 there were no issues installing the latest Tracy directly from the Module Repo. So this topic can be considered 'closed', as it's definitely not a Tracy issue but a dev core issue.

Thanks wbmnfktr, I did move the files manually and installed Tracy, resulting in a different 500 error upon trying to configure it. I suspect this to be a dev core issue rather than module issue. This is a new installation, so I can easily wipe this and start new. Edit: I also installed an old version of Tracy - or tried. Same error. And that version definitely used to work.

Hi, Are we the only ones who are running into this error during Updates and Installations of TracyDebugger? It is definitely a new error. Right now I cannot verify, but I want to say that I have seen it across various hosting environments. (I just ignored it before, because they were updates. Now I am trying to create a new installation. PW: 3.0.253 Tracey: latest from Git

The CustomPath module works fine for our purposes. Thanks for the hint.

Thanks to both of you. I did not see the custom paths module. This may work indeed, I will test it, as this is fortunately not a multi-lingual site. And yes, the name property is an option, I could rewrite the navigation module. But knowing the client, I am sure he will want exception for this flat url approach.

Hi, We have a client who insists on a one level url structure. They are used to it from other CMS. Example: Home menu 1 page 1 This results in the url /menu-1/page-1/ The client wants a custom url: /page-1/ I did unsuccessfully search the modules for a solution. I am currently a bit at a loss on how to achieve this without creating redirects manually through the redirect module or .htaccess. Has anybody already approached this case? Any input is appreciated. Adrian

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