dragan

It works here. Did you try this? $label = $templates->get("employee")->fieldgroup->getField('body', true)->label; echo $label; // displays "Zusätzliche Informationen" instead of the default "WYSIWYG Editor" label = tpl override

Perhaps you'll find a solution here:

I never worked with IIS, but here are a few related forum topics:

I really don't care. MS today isn't exactly what MS was 10-20 years ago. They've shown a lot of good will (and actions) when it comes to open-source lately. VS Code is a good, robust IDE - and completely free. MS is also actively involved in the W3C and many similar organizations. The Edge browser - though it will never become my browser of choice - is a solid piece of software. Eventually IE will be buried forever. MS didn't "get" the web (or open-source at large) in its early days, but they've "grown up", so to speak. They realize what's going on these days. What their particular motivation was for buying Github, we might never know. Maybe just a PR move, but really.... as long as you read the terms + conditions fine print in the coming days, and see for yourself what will be changed (if anything at all), I guess for most ppl it will be business as usual. You could also argue it was an "evil" step when Oracle bought mySQL. But did the product actually deteriorate or went the way of the dodo? No, it's still alive and well.

You could do this entirely just client-side, i.e. use cookies to store the pages and page-ordering. How would I save the page state? If you really want to save it in PW, simply create a textarea and save a JSON object, or maybe even a simple comma-separated list with page IDs would do the job. With Ajax, you would then simply post (save) a user-choice to PW, or retrieve it like that. No need to even use something like page reference fields.

You should also add dir to the html tag: https://www.w3.org/International/questions/qa-html-dir And of course the lang attribute too.

@thetuningspoon Thanks for sharing! Maybe @ryan could include that info in the official docs?

If your site is indexed by Google, and the number of pages or images is relately low, then you can try to get the cached version. But I'm not sure if that also works for images/files or just HTML.

I have upgraded several old (~4 yrs) PW sites straight to the latest dev version. The more you wait with upgrading, the more you'll have to change. Sometimes it just means adding PW namespaces, or upgrading modules as well. Sadly, I have no clue why this function causes problems. I just came across Ryan's announcement of this function: https://processwire.com/blog/posts/new-module-configuration-options/ This was introduced for 2.5.5. Maybe @ryan can shed some light on this...

I don't know either, sorry. But you could install + activate Tracy Debugger. Maybe next time these remove() methods are triggered, TD will reveal more infos. (just a guess - you have to enable TD also in the backend, of course)

Upgrading to which PW version? 2.x or 3.x?

yep. And / or: open the site in incognito mode. Everytime you close the browser in incognito mode again, the cache gets cleared automatically.

Maybe you need to set up something in .htaccess (my local dev server doesn't use ports, otherwise I'd try out something)

take a look here:

Yes, that's PHP, but you can also inject JS in a hook with $js = "<script>your script here...</script>"; $event->return = str_replace("</body>", "{$js}</body>", $event->return);

This this thread:

Try to delete everything inside the site/assets/cache/ folder. Maybe also try to clear your browser cache. Normally, you can move move around a PW site from anywhere to anywhere without such problems.

I don't really understand your question. Please explain "directly" and "field type"? PW inputfield types?

Create a "settings" template (name it whatever you want). You only need one field: title (or multilang title). Create a page somewhere. That will only serve as a parent / container page. Create as many pages underneath this parent page as needed. One page per select option. Then, in the template you want to build your form, basically do something like $settings = $pages->get(123)->children; // 123 is the id of the parent page foreach($settings as $s) { echo "<option value='{$s->title}'>{$s->title}</option>"; }

Sure. I have that installed as well. But very often, I need to do stuff that's not possible with that module, or simply easier to do writing a few lines of code myself.

That's a classic use-case for page reference fields. Create a dedicated page that acts as parent for all your product types. Underneath, create a page for every product option. Then you can easily foreach($page->children) etc.

Over the years, I accumulated so many custom API scripts, that I have decided at some point to simply include a special template in my PW boilerplate that holds all these utility / "batch-operation" API scripts in one place. In the template settings, I allow URL segments, and make sure access is for superusers only. This "API-scripts" template has (for better maintainability / readability) a simple switch/case that loads a certain .php file via include: So, if e.g. I need a quick listing / overview of all fields that a certain template has, I go to: mysite.com/api-scripts/fields - then I go back and lock the template again = comment the first few lines for security reasons (one can never be too paranoid...). For me, these are big time-savers, because even if you have to modify the included scripts for the current project, at least I don't have to search for these scripts over and over again and guess "where have I been using something similar the last time?" tl;dr: It's like having the whole PW-recipes site (and more) always at your fingertips ?

I guess it's a caching issue. Instead of action="./" I would add a pseudo query string to the form target (timestamp or random characters).

Do you have Tracy Debugger installed? Do you see anything suspicious there when loading that page?

ask @Sergio if he wants to share his module?