bernhard

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

Thx @matjazp maybe it has to do something with locale settings? Not sure, but I really just did the steps outlined in the github issue. No external modules (only processdatabasebackups to share the sql file)...

Interesting find. Though I'd ask you to try that again, because my issue is from 2019 so it should not have been introduced between .190 and .197 as they are a lot younger! I just checked replacing the wire folder from my example setup... 3.0.184 --> same bug 3.0.96 from 2018 --> same bug

Thx @Klenkes maybe you can try my submitted version?

I've created this issue back in 2019: https://github.com/processwire/processwire-issues/issues/916 Ryan seems not to be able to reproduce the issue 😐 Can you guys please try what I show here and see if that works for you or if you get the same issue like I do? Video: https://calip.io/O1wKadGz#cQZ1CRZf Here is a copy of that site for everybody to install: https://github.com/processwire/processwire-issues/issues/916#issuecomment-1120170931 Thanks for your help! @matjazp are you even not able to reproduce the issue with my copy?

@horst the password could be encrypted using the $config->userAuthSalt. For sending an email the module could load the encrypted password from the DB, decrypt it using the config salt and log into the mail account. That way an attacker would have to have access both to the DB and to your config.php file. https://stackoverflow.com/questions/9262109/simplest-two-way-encryption-using-php Though I don't know if it's really worth having that extra...

If you are new to hooks the linked post in my signature might be helpful 🙂 https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/?do=findComment&comment=158164