dotnetic

We need WebP support in the core as it only has advantages (and one disadvantage): Edge (yes, Edge) supports it, as well as Chrome, the Android Browser (since 4.2) and Opera. Firefox 65 which will be released in January 2019 will implement it very soon and the Safari team is also experimenting with it. The disadvantage is, that images that are being downloaded can not be opened with standard OS applications, but with tools like IrfanView or XnView you can also view WebP files. This makes it also hard to share these images and is why Facebook removed WebP from their service, as people tend to download and share the images. But I think thats not the case for most websites. And also it is a decision of the developer, if he uses WebP or another image format. So we have no drawbacks if this would be in the core (or a module, but I don't see why it should be a module).

Thank you @bernhard for another great tutorial. Written very well and very understandable.

In my opinion you can build amazing backend web applications with ProcessWire, as I already built some with it. A big difference is, that most frameworks like Laravel do not come with a backend. So you have to use Laravel Nova or Voyager to create a nice looking backend. ProcessWire on the other hand comes with a nice customizable backend. Depending of the type of backend/application you build, you have to "bend" the PW backend to your likings, this includes removing features, or writing modules to get the behaviour you would like (for example restricting users to a branch). In other frameworks you start with "nothing" or a boilerplate and develop the features you like, which might be more work, but you get a very tailored application. You could do this with ProcessWire also, if you like, because you don't have to use the included backend. What I was missing for example in Laravel Voyager were field dependencies, which hides or shows fields depending on the state of another field. One big drawback of ProcessWire is the sync between a live server and your dev server. Because ProcessWire does not distinguish between structural and content pages (or I am not aware of it), updating a live server with changes you made on dev is very cumbersome. There is some discussion about this going on here on the forums: or here

@Carel_S You are mixing things up. The widths of the fields in the template admin only have effect in the admin/backend. They are not meant to be used in the frontend. However if you want to use the with of a field on the frontend, you can do so like described here Edit: you found it out yourself quicker as I could post my answer

First of all, thank you for this great module. Simplifies the whole process a lot. Now please add Drag 'n' Drop of the fields and support for adding new fields to the template. Also add field edit links to open the field editor in a popup/pane. Switching between the field name and the field title would also be nice. And if you could display what fieldtype each field has. And voilà we have a new and better template manager ? Hey, I am allowed to have dreams.

Yes, what @Zeka said can be used: $(document).on('pw-panel-closed', function (event, panel) { window.location.reload(); //console.log(event); //console.log(panel); });

Thank you @Gadgetto for taking our improvements into account and updating you tutorial. However, I spotted a small error in your screencast/animation: If the language is switched to english then the word "german" instead of "Deutsch" appears. As you wrote yourself in your tutorial, the language should be written in the language itself ? I am happy to welcome another happy ProcessWire addict into our community ?

@Gadgetto I wanted to say the same as @bernhard said, but he was quicker. Flags are no indicator for languages but indicate countries instead. This is something I constantly tell my customers, that want to have multi-language sites. For a good implementation of a language switcher take a look at https://www.p-jentschura.com There I follow best practices for a language switcher.

Another hint: Use a browser without installed extensions. For example Chrome in Incognito mode. Maybe an extension causes the slowdown.

THIS. IS. AWESOME. @adrian: A nice guy who never sleeps and always is improving. Master of Tracy and other girls ? Thank you. The autocomplete is, well I said it before: AWESOME!!!!

Actually it's very easy. You can get the email of the page creator with $page->createdUser->email

Shopify (Lite) is easy to integrate (Buy button or other solution) and can be styled to fit your likings. However, you have to pay fees to use it and also if you use external payment providers. But it looks nice and can be customized.

Hey guys, now the language pack is also linked in the modules directory at https://modules.processwire.com/modules/german/

Please use the new thread for discussion from now on.

I second that what @AndZyk said. It is not a good thing to omit the different URLs for each language. The term URL means Uniform resource locator, and should excactly do this. Locate a resource (for example the french version of an article). So if someone wants to bookmark the french version of an article on your site, he can not do it with your logic. Instead he has to switch to french everytime he visits. Also from a SEO perspective this is very bad, because content in other languages can not be crawled. Why don't you want to use language folders like /en/? What is the purpose?

Thanks @bernhard. Yes I will post instructions and improvements as soon as I have a little bit time. Thank you for offering your help.

The language pack is available at https://modules.processwire.com/modules/german/ or in the github repository https://github.com/jmartsch/pw-lang-de/releases/tag/latest The master branch will (try to) be up to date with the most recent stable version of ProcessWire. The dev branch will (try to) be up to date with the most recent dev version of ProcessWire. If you find any missing translations or errors, please create a PR or submit a bug/improvement. I hope we as a community can work together, to update translatations as soon as a new dev branch is pushed. Please let me know if you want to translate a new dev version, so we are not both doing the same task. If you want to help, you can clone my ProcessWire environment for language packs which provides an easy way for translating a language pack. You simply clone it, make changes to the language in ProcessWire and commit the changes back to your (or the german) language pack repository. This is a boilerplate which could work with any language, but right now it is tailored to the german language pack. Then I am able to quickly release an updated stable language pack when a new ProcessWire stable version is released. Big thanks to @Nico Knoll and @yellowled for their initial work on the translations.

I just released the updated translations for ProcessWire dev 3.0.118 at https://github.com/jmartsch/pw-lang-de/releases/tag/3.0.118

I am proud to anounce, that I am the new maintainer of the github repo now. I will add my translations for the dev version very soon. Thanks to @yellowled for handing it over to me.

@yellowled Hey, thanks for the quick reply. Yeah, I would like to take over. My username on github is jmartsch. You can transfer the ownership to me and I try to do my best to update the language pack (with a little help of the community).

@yellowled Hey Matthias, I forked the repo and made a dev branch for latest PW dev version 3.0.118 and added all missing translations and removed abandoned translations. What do you think about also implementing a dev branch into your github repo and merge my changes? I try to update the dev version as soon as I can when a new version comes out. When we work like this, we quickly have a german language pack available when a new PW stable version comes out. You can find my dev branch here: https://github.com/jmartsch/pw-lang-de/tree/dev

Is https://github.com/outflux3/ContextHelpTemplate really meant to be used in conjunction with ProcessDocumentation, or is it just for AdminHelp? Because it seems to be very tailored to AdminHelp. I installed it, and set the setting to open in modal, but my "Dokumentation" menu item link still opens a normal page.

So you have to recreate your help folder structure in admin, right? I have to say that this is very cumbersome. It would be easy if you just create ONE page under admin with process "ProcessDocumentation" and select a page from the page tree. If that page has children, display them somehow (in a list, as submenus, etc). This could be configurable. This would make this module a lot more user friendly.

@Macrura Thank you for the quick answer ? I done that before, but then changed the process to "ProcessList" as you wrote in your inital post, because I want to show the children in a list. When I revert to use ProcessDocumentation for the page, I just get the default behaviour. I selected a page that is in the page tree, not under admin, so my customer can change the content if he wants to. Now the documentation menu item takes me to the page I selected, but how do I get a listing of the child pages on this page?

@Macrura I tried to make a folder structure, but it does not work. First I created the page "Dokumentation" which has the process "ProcessList" assigned, as you wrote. And it has two children with the template "documentation". The menu item "Dokumentation" appears (I am using AdminThemeUikit), but when I click on it, I am redirected to a page that says: "The process returned no content." So what did I do wrong? Maybe you can describe the exact steps to be taken, to get a folder structure documentation. Another question: Is it possible to render the page in a panel instead of redirecting?