bernhard

I did not try, but maybe you could redirect any non-ascii url to some custom php file (like redirect.php in the site root) and that file could bootstrap PW and redirect to the new page? Something like this: # Redirect URLs with umlauts to redirect.php RewriteCond %{REQUEST_URI} [äöüÄÖÜ] RewriteRule ^(.*)$ redirect.php?url=$1 [QSA,L] <?php // Include ProcessWire bootstrap include "index.php"; // Get the URL from the GET parameter 'url' $url = isset($_GET['url']) ? $_GET['url'] : ''; // Sanitize the name using pageNameTranslate $pageName = $wire->sanitizer->pageNameTranslate($url); // Find the page with the sanitized name $page = $wire->pages->get("name=$pageName"); // Redirect to the found page if ($page->id) { $session->redirect($page->url); } else { // Handle the case where the page is not found $session->redirect('/'); }

Everybody using the cool ajax endpoints feature please update to v3.16.1 as it contains an important fix (added missing return statement in public endpoints). @gebeer

I don't think it's off, because in ProcessWire we have both the Frontend and the Backend. As far as my research took me I don't think that Strapi offers that, does it? So you have to build your frontend on your own, add another tool and tech stack...

v1.7.0 now ships with all DejaVu fonts by default, so you can use all combinations of bold and italic text without the need of adding custom fonts beforehand ?

Update: The module is now available in the modules directory ?

If the developer of your website hasn't implemented such a feature, you won't be able to find it. ProcessWire will only let you do things that the developer thought were a good idea. And many developers will probably think that letting the client insert untrusted code is not a good idea... You'll find the code of the website on the server. Usually you can connect via FTP or some hosting providers have web based file management tools. From there it should be quite easy to find the file to put the code into. Usually it will be in the /site/templates folder. If you have a _main.php file there this will most likely hold the main markup of your website that all pages use. If not you can open /site/templates/home.php or /site/templates/basic-page.php and inspect the code there. If those files all have something like <?= include('sections/footer.php') ?> you'd put your markup in one of the included files that get's included by all templates.

Hey ProcessWire friends! @protro asked something about Strapi in another thread, so I did a quick research on how to build a basic frontend for content stored in Strapi and found this 20+ video on youtube: Now, don't get me wrong, Strapi is cool and all and the video is really great, but I couldn't help but chuckle thinking about how we do basically the same in ProcessWire. Here's our "epic" version: <?php foreach($pages->find('template=faq') as $faq) { echo "<div><h2>{$faq->question}</h2>{$faq->answer}</div>"; } Boom! Done in a few lines. No need for popcorn or a comfy chair. ? Cheers to simplicity and efficiency! ? #ProcessWireFTW #KeepItSimple #LessIsMore

Hey @netcarver and @gebeer great news for you (and all RockFrontend users) I've fixed an issue with ajax endpoints not replacing ALFRED markup (thx for the report @gebeer) and while working on that I got quite a lot of errors in the console about the livereload stream having a wrong mimetype, which has also been observed and reported by @netcarver some time ago. So I fixed that as well ? Please try the latest version on the dev branch, which will be merged to master in some days. LiveReload only reloads the visible tab. This is to avoid endless loops where one window reload causes the other one to reload as well and vice versa. In older versions you had to reload the tab manually once you switched back to it. In the latest version it will wait and as soon as you switch back to the tab it will be reloaded automatically if a file changed in the meantime ?

Thx @adrian I have to clarify this: In my inputfield (InputfieldRockGrid, but could be any inputfield) I have added a method "renderReady" like so: <?php public function renderReady(Inputfield $parent = null, $renderValueMode = false) { $grid = rockgrid()->getGrid($this); if (!$grid) return; wire()->modules->get('JqueryUI')->use('modal'); // load all dependencies // this can safely be called multiple times // it will only load the assets once $this->wire->config->scripts->add( rockgrid()->url(__DIR__ . '/lib/tabulator.min.js', true) ); // some more assets here return parent::renderReady($parent, $renderValueMode); } I always thought this would be the way to go when creating inputfields/fieldtypes, but renderReady is never triggered. That's why I created the hook shown in the first post, which is executed on the parent's "render".

I'm having some troubles with using the renderReady method of inputfields. The first problem that came up was discussed with @adrian here: https://github.com/baumrock/RockAdminTweaks/commit/1c327039f22138725c2dfdc9e659525f2f59011b#commitcomment-142442415 It looks like the renderReady() method is never called for InputfieldCheckboxes. Another problem came up today when developing RockGrid. That inputfield needs some JS+CSS assets to be loaded whenever an inputfield of this type is rendered in the backend. I thought loading the assets in renderReady would be the right thing to do. But it does not work if the field is inside a repeater. I used this hook to fix this: <?php public function init(): void { wire()->addHookAfter('Inputfield::render', $this, 'preloadRockGrid'); } protected function preloadRockGrid(HookEvent $event): void { // if it's not the repeater field exit $f = $event->object; if ($f->name !== self::field_variations) return; // loop through all fields of the repeater and load their assets foreach ($f->hasField->fields as $fname) { $field = wire()->fields->get($fname); $inputfield = $field->getInputfield($event->process->getPage()); $inputfield->renderReady(); } } This works but it is really hacky and I'd like to have a proper solution for the problem and try to understand better what's going on and why things do not work as expected. Can anybody shed some light on this?

Hi @Christophe I can't reproduce. Please provide step by step instructions then I can try to fix it.

Thx for sharing! I'm not having any issues, so I'm wondering why? I'm using latest UIkit and latest LESS module. Do I have to adjust something specific? Would it be worth to create an issue for the uikit team so that they can account for that use case?

@FireWire have you considered using WireHttp for the requests?

Another very interesting approach by @netcarver and @FireWire:

Hey Ryan, thx for these additions! I'm wondering if there is a way to open a modal and then react/wait for something within that modal. For example we could maybe create an action for a page reference field to create a new page. When the page is successfully created in the modal and the modal is closed we could trigger the inputfield's reload event and the user could instantly select the newly created page.

@sebibu you can easily hook into https://processwire.com/api/ref/session/login-success/ and add the last login timestamp as $page->meta('lastlogin', time()) on the $user object (for example).

AI help sounds good: Certainly! You can use a hook to modify the output of a Page Reference field when it is set to "Open + Locked (not editable)" by hooking into the `renderValue` method of the `InputfieldPage` class. Here is an example of how you can achieve this in ProcessWire: // Add this to your site/ready.php or a custom module $wire->addHookAfter('InputfieldPage::renderValue', function(HookEvent $event) { $inputfield = $event->object; $page = $inputfield->value; if($page instanceof Page) { // Modify the output to include a link to the referenced page $event->return = "<a href='{$page->url}'>{$page->title}</a>"; } }); This hook will intercept the rendering of the value for `InputfieldPage` fields and modify it to include a link to the referenced page. Make sure to place this code in a file that is executed on every request, such as `site/ready.php` or within a custom module's `init` method. For more information on hooks in ProcessWire, you can refer to the https://processwire.com/docs/modules/hooks/

Seems that they dropped PW for their sites... Same here

It might also be worth mentioning that there's also a RockFrontend site profile now that has tailwindcss support: https://github.com/baumrock/site-rockfrontend ?

Hi @Ash and welcome to the forum! It sounds like ProcessWire should be a great fit for your requirements! IMHO you have two options Build a custom UI on the frontend Use the PW backend 1 has the benefit that you can build it however you want with all the tools and workflows you already know. It has the drawback that you have to build everything that is necessary (user registration, all kinds of security mechanisms etc). Basically you are building a mini-CMS for your clients and we already have a great CMS at our hands ? 2 has the benefit that it is a well established platform for content management, and what you are trying to do sounds like content management to me ? The drawback is that you have to first learn how the backend works and how you can customise it or how to develop your own modules with custom workflows. Which way is preferable depends on you, your skills and your needs (and your clients). Is design and a good UI/UX very important? It might make sense to build a custom UI. Is it more important to be cost effective? Do you want to build on a solid foundation? Are you willing to learn PW and also benefit from the knowledge for future PW projects? Then diving into PW backend development might be very worth it. I took the backend pill years ago and don't regret it ? I don't know what exactly you are asking, but the short answer is "yes". ProcessWire is great at working with data, either from the UI or also from the command line. And it has always been - see this ancient post from 2010, for example. Nowadays we even have an API for reading CSV files line by line, so an import script could be as simple as this: <?php while($row = $files->getCSV('/path/to/foods.csv')) { $p = new Page(); $p->template = 'food'; $p->parent = 123; // page id of parent $p->title = $row[Food]; $p->type = $row[Type]; $p->color = $row[Color]; $p->save(); }

Unfortunately I have no idea what could be the issue. The only thing that looks weird to me is the capital M in the template name Motif-sub-layout. I'm never using capital letters here, although I know they are allowed - so it might be totally only a personal preference and nonsense in this context. Just wanted to mention that this might be worth testing - maybe your local dev file system is not case sensitive and your remote one is, or similar? I don't know, but it might be worth a try ? Good luck! Other than that I'd try to revert as much as possible on the remote (maybe remove or uncomment almost anything in the pageclass) and try to see if it works at some point. If so, then jackpot, then you can add things back in and see when it starts to break.

Another update: More info() settings! Please check out v1.8

Thx, makes sense! I've fixed that and merged almost all of your PRs ?

Yes, translations are saved in in /site/assets/files Enter some-unique-string-german in one of your fields Save the page Search your codebase for the string "some-unique-string-german" And you'll know where PW stores that information.