bernhard

Great solution ? Imho $page->siblings()->last() and $page->siblings()->first() would be a little bit easier to read ?

Thx @DaveP I'd prefer to get a better understanding of how to customize ckeditor to my needs rather than fixing/rewriting things afterwards ?

You can use https://doc.nette.org/en/utils/validators#toc-isemail I think that should work? Or just copy the single method? https://github.com/nette/utils/blob/35f77d3cef633ea75c1a620f40211b1494bfe00b/src/Utils/Validators.php#L304-L319 $isEmail = function(string $value): bool { $atom = "[-a-z0-9!#$%&'*+/=?^_`{|}~]"; // RFC 5322 unquoted characters in local-part $alpha = "a-z\x80-\xFF"; // superset of IDN return (bool) preg_match(<<<XX (^ ("([ !#-[\\]-~]*|\\\\[ -~])+"|$atom+(\\.$atom+)*) # quoted or unquoted @ ([0-9$alpha]([-0-9$alpha]{0,61}[0-9$alpha])?\\.)+ # domain - RFC 1034 [$alpha]([-0-9$alpha]{0,17}[$alpha])? # top domain $)Dix XX, $value); }; db($isEmail("post@kirchlein-im-grünen.de")); // true

Hey @ryan thx for the tab update ? I've played a little with the getMultiple() method. Not sure if I'll use it a lot or not, but taken this example: I'd prefer this: extract($page->getMultiple('foo,bar,baz', true)); So I was wondering if we could have something like this? $page->extract("foo,bar,baz"); echo "$foo<br>$bar<br>$baz"; But I think that is not possible without the extract() call, is it? Also I'm wondering if using list() is better than using extract()?

thx @pwired that worked for me ? The input for the customOptions inputfield is this: enterMode: 2 how did you find that setting? I'm always lost when customizing the ckeditor...

<?php foreach($pages->find("parent=1223|1224|1225") as $teaser): ?> <a href='<?= $teaser->url; ?>' class='teaser-angebot-wrapper <?= $teaser->parent->select_color->title; ?>'> <section> <h3><?= $teaser->title; ?></h3> <?php if($teaser->parent->id == 1223): ?> <p>Ausstattung: <?= $teaser->textfield_01; ?></p> <?php else: ?> <p>Wo / Wann: <?= $teaser->textfield_02; ?></p> <?php endif; ?> </section> </a> <?php endforeach; ?> I've recently become a huge fan of the latte template engine (by the folks that made tracydebugger) as it produces so much cleaner output in your templates and that would be a perfect example: <a n:foreach="$pages->find('parent=1223|1224|1225') as $teaser" class='teaser-angebot-wrapper {$teaser->parent->select_color->title}' href='{$teaser->url}' > <section> <h3>{$teaser->title}</h3> <p n:if="$teaser->parent->id == 1223">Ausstattung: {$teaser->textfield_01}</p> <p n:if="$teaser->parent->id == 1224">Wo / Wann: {$teaser->textfield_02}</p> </section> </a>

Thx @flydev ?? would you maybe have time to post a tutorial with all the steps necessary to get started with ProcessWire + Vite to get all the modern frontend tooling + live reloading + working PW backend? That would be great! Or maybe @dotnetic What is ProcessWireMix() or what does it do? Has anybody used uikit with purgecss and can show me how to do that? @Tom.

@cb2004 I've looked into flarum over last two days and it seems to be a good option and could be a good fit for ProcessWire as it uses the same technology on the server side and could even use the same database. Any chance to see what you did? @breezer have you thought of integrating an existing solution into PW rather than building something new?

Hi @breezer is your new forum different to the one you mentioned in 2018 with a similar post?

Just because there is no need for this extra. The client is happy what he got. Coming from Typo3... That extra would be 1 module to install and 2 settings to populate... Just saying ? The site looks great - congratulations ?

Hi @olafgleba thx for that question. I'm only using webpack because the company where I'm working now is using it, which has historical reasons and might change soon. I never got used to browsersync - maybe that would be easier ?

Hey @Wanze do you plan to do something about the PHP 8.1 errors? ? https://github.com/wanze/SeoMaestro/issues/41 Thx in advance!

Ryan helped me to find the issue in another related thread: https://processwire.com/talk/topic/27136-page-list-view-page-path-points-to-localhost/?do=findComment&comment=224041 ?

Hey Ryan, thx!! Your pointers helped me to find the issue. I simply had to change the proxy url from https://my.ddev.site to http://my.ddev.site then all my backend view links are HTTP links to localhost:8080 and work as expected ? Great! Update: Ok it was a little more complicated but it works: I added custom headers to the webpack proxy: devServer: { watchFiles: watchFiles, compress: true, devMiddleware: { publicPath: '/site/templates/' + bundleFolder, // webpack output is served from this path }, proxy: { '/': { target: 'https://my.ddev.site', secure: false, changeOrigin: true, headers: { 'X-Proxy': true, } } }, } And then I set the config accordingly if the header is present on my dev config file: $config->httpHosts = ['my.ddev.site', 'localhost:8080']; if(array_key_exists('X-Proxy', getallheaders())) { $config->httpHost = 'localhost:8080'; $config->https = false; } Now we have live reloading whenever a file changes and not only a working frontend but also a working pw backend served via localhost:8080 ?

Hey @ryan I have a related issue where httpHost = "localhost:8080" is not working as expected: https://processwire.com/talk/topic/27110-how-to-work-with-site-on-localhost8080/ I have this config (for webpack live reloading): $config->httpHost = 'localhost:8080'; $config->noHTTPS = true; The backend works and all links from the backend into the backend work (page edit, modules, etc). But links from the backend into the frontend (all "view" links, both in the page tree as well as the "view" tab on the page edit screen) do not work because PW makes HTTPS links instead of HTTP.

Hey @Richard Jedlička just wanted so say thank you as your module is really helpful in my daily work ? Also thank you for your suggestions regarding RockMigrations field context syntax, I'm using that all over and it makes the migration syntax a lot better!! ?

Thx @skeltern could you please report your findings here: https://github.com/processwire/processwire-issues/issues/1341

For me the opposite is true ? The main reason for that might be my workflows around RockMigrations and custom page classes. Having the fields defined in code directly in the page class is so much easier for me than any other approach I tried. So those additions where very welcome ones for me ? Need some new data for a boat? Go to the boat pageclass file and add a field there. Need a new field for every blog post? Go to the blog post pageclass file and add it... I'm only sharing fields across templates (page classes) when they really have the same purpose (eg a RockMatrix field for the pages content that has several content-blocks like headline, text, quote, etc that should be the same for templates home, basic-page and blog-item). So adding a new content block like "image" for example would make it available on all those templates immediately compared to having to update all templates one by one and adding the new image block to three different fields. For me it feels a lot better to have a single field for a single purpose. Sharing a field for different purposes by overriding settings in template context never felt good to me... I'm using template context a lot, but only to do simple modifications like tweaking the field's label (eg of the title field). One huge benefit of such an approach can be that you get reusable components that you can simply copy from one project to another. That's because the page classes do NOT share fields with other components of your site and therefore are self-contained parts that work on their own. That would not be possible if you shared fields from a central place. Or it would be a pain to reuse single parts of that website. I have been there. I don't want back ?

Congrats @ryan that's a really great achievement ? Also thx to @matjazp for all your help on the github issues - great work!

Hi @Marc I try to explain it again ? The problem is that if I run "npm run serve" the webpack devserver is responsible for serving the JS and CSS assets. The cool thing about that is that the browser will reload automatically whenever a file is changed which is especially handy on frontend development. This works great as long as you are on the devserver host, wich is http://localhost:8080 in our case. We don't have HTTPS here as it is not easy to setup (according to my colleague). The problem is, that when I want to change something in the backend (eg for creating pages) I head over to http://localhost:8080/processwire. So far so good. Then I create a new page. Also good. But then I hit "Save + View" and I end up on an error page as PW tries to open HTTPS://localhost:8080 instead of HTTP. Same goes for the "view" tag in the page editor and also the "view" action on the page tree. Hope it is clear now?

Hey @AndZyk thx for your ideas! ? Yes, I've tried that, thx, but it will always use example.dev - no matter which sort order I use ? Yes, thx, I'm using that for a long time already https://processwire.com/talk/topic/18719-maintain-separate-configs-for-livedev-like-a-boss/ - the problem is that the local dev config can either have host example.dev OR localhost:8080. That depends on wheter I run "npm run serve" or not. Ok I can change the host in the config file based on SERVER request uri I guess... Thx, I've tried that one as well but all view links are still being https...

Translations are a topic on its own, especially with migrations... If you need to create Pages, in RockMigrations you can do this: $rm->createPage('Your page title', 'your-page-name', #parentpage, ['hidden', 'locked']) Which will create the page only if it does not exist. This might be what you need or not. You can create pages very easily via the PW API... Or use import/export tools. Don't know if there are limits regarding the amount of pages.

We are working with webpack and have a devServer running and proxying requests to our DDEV powered pw site. That way we get live updates for frontend development when we save any file that is watched by webpack. To get live updates we run "npm run serve" which makes the pw site available under localhost:8080 The backend also works on localhost:8080, but what annoys us a lot is that once we click any of the "view" links in the backend, we land on the regular ddev url (which is something like mysite.ddev.site) which due to webpack does not have any of the JS and CSS assets in place and therefore is not usable... It seems that ProcessWire is using the host of $config->httpHosts and not the current browser URL that it is running on. Is there any settings we can change to make the backend show edit links with localhost:8080 ? I've tried changing $config->httpHosts to 'localhost:8080' but then the backend uses HTTPS urls for the view links even though the template settings say HTTP or HTTPS (or even with HTTP only I get HTTPS urls). Also changing the config file whenever we use npm run serve is a little tedious... Any ideas how we can improve that? Thx!

RockMigrations was built for exactly this purpose and has been in development for 3 years now and I'm using it on a daily basis for all my projects. The new version is already online, ready to use and so much better and easier than the old version ? I just have not released it yet because I plan to do a video introduction for it so that it is easy for everybody to see how it works and how easy it is to use. https://github.com/baumrock/rockmigrations The new version has a helper for github actions for fully automated deployments. So when set up correctly all you have to do is "git push" and everything on the live server will be updated. When working locally all you have to do is to restore the live database. RockMigrations has a files-on-demand-feature that will automatically download any missing assets from your live server: https://github.com/baumrock/rockmigrations#file-on-demand

Thx, that seems to be the missing piece! https://calip.io/1TJBAzco#RHR92CVm