yellowled

@jmartsch Great! However, you'll have to rename your forked version – since you can't have two repos of the same name, I can not transfer the original. I'll get in touch via email so we can also give you access to the module directory entry.

@jmartsch Here's the thing – sadly, I haven't done anything with ProcessWire in a long time. I would like to, but switching from being self-employed and building sites for clients to being employed at an agency and focussing on frontend has kind of pulled my out of the loop here. Of course, just maintaining the lang pack is not a big thing, it's basically just merging pull requests on my end. However, I feel like this should rather be maintained by someone who is more actively involved with the community. How about I hand over the ownership of the lang pack repository to you and you become the new maintainer? (Yes, I'm serious.) :-)

Swiftly updated for 3.0.61, thanks again to Manfred. Everyone, enjoy and please report anything you may find wrong or worth improving, ideally in a pull request at https://github.com/yellowled/pw-lang-de, please.

Once again heads up, everyone, I just now updated the “stable” German language pack for 3.0.34, which – as usual by now – means a lot of work, mostly by Manfred, (translating all the things) followed by a little work by me (merging). As usual, thanks to all the contributors, especially Manfred for his tireless efforts and Robert, who took the time to iron out a looooooot of small mistakes. Everyone, enjoy and please report anything you may find wrong or worth improving, ideally in a pull request at https://github.com/yellowled/pw-lang-de, please.

That is a huge part of it, yes. As I said, this site used to run on Contao. Contao's way of handling this is two seperate page trees, which means every time you so much as edit a page, you have to do it twice in two different places in the backend. Now it's just a click away on the same page. This is a great testament as to how well the PW backend works in general and completely unrelated to which backend theme one chooses to use. I may be “surprised” by how well all this works since I haven't even so much as tested the multilingual stuff in quite a long time. When I last checked this out, languagefieldtabs was still a separate module! I remember when it wasn't easy to have a page exist in one language, but not in another – now that's just a checkbox to uncheck. I also remember when we did not yet have language-specific image descriptions. This really has come a long way, and it has improved as well. Very good job by everyone involved.

So it finally happened – I (re)launched my first multilingual site built with PW. For the first time, I do not have to mention that the site is in German only and most of you will probably not be able to etc. etc. blues-baltica.de is a site for a couple of events surrounding the most important of them – the BluesBaltica or Bluesfest Eutin, which is considered to be Europe's second most important Blues festival. It will take place for the 27th time in a couple of weeks, as it does every year in May in the small town (about 17K people) in northern Germany that I live in. It's an admission-free, open-air festival. In addition, the association organizing it also hosts the German Blues Challenge & Awards, which is the German qualifiers for the International Blues Challenge in Memphis, TN. Okay, technical stuff. It's multilingual, which is the biggest thing about it for me since it was my first multilingual site. And it's been a blast. Seriously, all that multilingual stuff in PW? The multi-language fields, the alternate language fields, the tabbed interface? It's friggin' perfect. Whoever came up with all that is a genius. Other than that, it uses just a few modules, most of them are my “go-to modules” that I use in every project, like Markup Simple Navigation and Markup Sitemap XML. Used Hannah Code for the first time to include the code for the Piwik opt-in iframe in a WYSIWYG editor field – works like a charm. Also use Scheduled Pages since this site sometimes needs news posts to go live in the middle of the night. And Export Site Profile because it's the easiest way to back this up regularly. As for the design, it is a bit “special” because the main organizer, who is my contact person, it a bit particular about it. Also, they really don't have a huge budget, so this is kind of a pet project anyway. The main objective besides moving away from the old CMS really was to make it easier to maintain in the backend. But it is HTML5, responsive and even uses SVG sprites for icons, and hopefully performs well for everyone despite the about 60 301 redirects it needed after moving from Contao to PW.

As mentioned before, I went with RewriteRule in .htaccess, which works well. I'm not sure anything else would have worked here because in addition to being multilingual, the original site also used different page titles in both languages, i.e. /foo.html in German could have been /bar.html in English. I have only skimmed the thread you linked to, so I'm not sure if Jumplinks could manage that.

Thanks for the input, guys. So here's what I ended up doing in case anyone stumbles across this in the future: I found a post by Ryan via search which explains how to set up 301 redirects via .htaccess in PW (I ran into the error which is mentioned there as well). You can shorten Ryan's rule there by using “[R=301,L]”, but other than that, that's how it works. I now have about 50 “plain” rewrite rules (redirecting foo.html to /bar/) and about 10 using a regexp. I don't notice a performance hit (I have no way of measuring properly, though; it's shared hosting), also 2 people working at hosting companies have assured me that RewriteRule should not affect performance (on a properly configured Apache).

I have not. I assumed that this was/is meant for URL that change “within” ProcessWire, i.e. if I change /foo/ to /bar/ and have already placed links to /foo/ etc. This is about a site that currently runs on Contao and is being ported to PW, so I need redirects from /foo.html to /bar/. I just realized I probably don't want to use ProcessRedirects anyway since it will need a fair amount of redirects. That's got to be a preformance hit at some point, right? We're talking about 60 Redirects altogether here. Also, I'll probably need some RegEx redirects, that's not even possible using a modules, is it?

Basically just asking to confirm, but since I could not find any results – I'm currently rebuilding a multilingual site in PW. That means a lot of URLs changed. I usually like to use ProcessRedirects for that, but it does not seem to want to accept my multilingual URLs – the /en/ prepended to English pages (default language is German) is removed from any URL the Redirects list in the backend (yes, I double-checked). Is the Redirects module not “compatible” with multilingual sites, am I using it wrong or do I have to enter all those 301s in the .htaccess?

Client's site (still working with PW 2.4.0 there, by the way) needs permissions based on roles, not users, as discussed previously in this thread. Back then, I decided to use PageEditPerRole because it seemed the more polished alternative of two proof-of-concepts. Of course, clients always find a way to expose weaknesses in the system that developers would never ever have thought of. In this case, it seems as if it is not possible to assign edit access to roles for a page and its child pages if said page is unpublished. I already tested it, if users are assigned another role which has edit access for said pages and is not limited by PageEditPerRole, it works. And of course, the client would like to use just that, i.e. limit access to a group of unpublished pages based on a role. I'm not a coder and I have been out of the loop on ProcessWire for a while, but my assessment would be that a) this is not an issue of the core, but of the module b) apparently, the module does not “see” unpublished pages (I hope it's clear what I mean by that) c) therefore, the module does not allow to limit access for role to (a) page(s) that is/are unpublished First of all, it would be great if someone could take a look at the module and tell me if I'm assuming correctly. (As I said, not a coder.) Second, can anyone think of another way to achieve this for unpublished pages? I have yet to search the forums, but I have searched the modules directory and there does not seem to be another module. I read about changes to permissions in ProcessWire 2.6, but I'm not comfortable with using a dev version here (very, very inexperienced CMS users as editors, plus it's a non-profit with a very limited budget for support).

Heads up for everyone, I just now updated the “stable” German language pack for 2.6.0, which – as usual by now – means a lot of work, mostly by Manfred, (translating all the things) followed by a little work by me (including a manual merge this time ). As usual, thanks to all the contributors, especially Manfred for his relentless efforts. Everyone, enjoy and please report anything you may find wrong or worth improving, ideally in a pull request at Edit: Yeah, URL would have been good, right? Report at https://github.com/yellowled/pw-lang-de, please.

I'll make this quick since these are pretty boring given the fact that in both cases, the original design was not done by me but is based on print designs originally intended for flyers. Both sites actually belong to the same client, a local non-profit organization providing help and counceling for women (abuse, domestic violence, mobbing, stalking but also pregnancy, divorce etc.). Both sites used to be static pages (both technically and design-wise), they have now been upgraded to responsive designs powered by PW. frauennotruf-oh.de (the main site of the organization) maedchenberatung-in-oh.de (a one-pager tailored to girls and young women who prefer counceling via email) The most remarkable part was (once again, I might add) how easy it can be to convey using a CMS with PW. None of the client's editors had ever worked with a CMS before, yet we still managed to get the CMS training done in 90 minutes for both sites. Everyone was pretty surprised how easy it can be to manage your own website with PW.

Late to the party (as always), but anyway: if you're thinking about static site generators, I have always found that they are limiting in one way or another. A lot of them are “blog-aware”, which translates to “anything that is similar to a blog will be built quickly, everything else will take hours and be painful”. Just my experience with them. A nice alternative is assemble, because it does (much like PW) give you a lot of freedom to work the way you like to work. It's basically a Grunt plugin which generates static HTML from Handlebars templates. It's kind of clumsy to do certain things (like i.e. building navigations dynamically) and they're apparently in the middle of rewriting the whole damn thing (for quite some time now), but if all you need is a small template system to be able to use variables, partials/includes and layouts in HTML, it's worth a shot.

Discussion can be continued even if the issue is closed, by the way. That being said, I always felt that GitHub issues are not a good place for discussions or feature requests anyway, but I guess that depends on how one wants to use GitHub issues. I really don't follow the PW repository closely enough to even comment on that, it's just my experience from other projects that discussions and feature requests tend to extend issues to a length close to being unreadable. The same is true for the number of open issues or pull requests – it really depends on how someone looking at the repo views them. I know I tend to shy away from projects that have a lot of open issues and PRs, but one should in fact always look at the commit log as well to check how active a repo is. Maybe a hint concerning all this in the README (“How Processwire handles issues and pull requests” or something) would help clear that up?