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.

The genius here is I believe adamspruijt for creating languagefieldtabs 

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.

See this thread and let me know if it helps

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).

Have you tried the PagePathHistory module? It handles the redirections automagically under the hood whenever you change a pathname.

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.

Oh, I didn't know that not everybody can reopen issues.

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?

@yellowled try this:

Thanks, I actually found that option myself in the meantime.  Also nice for the grunt folks among you: there's a grunt task to start localtunnel. 

Might not be as comfortable as similar solutions mentioned here (the generated subdomain URLs are pretty long and clumsy to type on mobile devices), but http://localtunnel.me is another node.js thingy to forward your local dev server.

Some crazy dudes from Germany obviously like the CMS too 

It's called “German efficiency” for a reason, you know. 

I know that using PW compared to many others can make you FEEL like you have died and gone to heaven, but as far as I am aware, Matthew is still very much with us!

Well, his web site is currently throwing a 509 Bandwidth limit exceeded … 

No, seriously, apologies for that. I like to think of myself as someone with a pretty decent knowledge of the English language, but at the end of the day, I'm not a native speaker. (I wasn't really sure about the particular idiom. Should've looked it up. Sorry, Matthew.) 

In the spirit of Matthew Following Matthew's example, I'm going to be boring and actually take this serious. Sorry guys, no funny images here. 

Before: I was basically switching my “go-to CMS” every, phew, 6 months or something like that? I'm not going to list them all since I don't see the point in that, but suffice it to say that I have at least evaluated almost any CMS that regularly shows up in one of those “most popular open-source CMS” lists. And frankly, they basically all suck in one way or another. As Matthew stated, it was basically looking for the lesser evil for any given project.

After: I just looked it up – the last time I built a new site with a CMS other than PW was September 2013 (explicit client's request for a specific CMS). I frequently do freelance frontend developement for an agency which uses TYPO3 for almost everything, and I catch myself thinking “Boy, how easy this-and-that would be in ProcessWire …”

In fact, I finished a project the other day which was built in static HTML because (project management voice) “… a site like this can't be implemented with a CMS.” It could've been. Easily. Just would have had to use the right CMS.

Most important of all, and this is what I always mention when I talk to people about ProcessWire, I'm now actually having fun implementing sites. That used to be very different back in the day.

As for calibration – it probably won't satisfy the needs of a photographer, but I got myself a Spyder 4 Express a few months ago (got it on sale, too). I have a (rather crappy, cheap) monitor here which is for my (rarely used) Windows machine, but I also use it as an external display for my MacBook every now and again because the MBAs display only goes to 1440x900.

Boy, did using that tiny thing improve the colors on the old Samsung display. And it's incredibly easy to use as well. I probably wouldn't have spent money on that if the Samsung didn't for some weird reasons have really bad colors ex works. (And I would never want to adjust a monitor without it ever again.)

That being said, I'm with apeisa here. If you're getting it for yourself, fine. Nothing wrong with that. But if you mean to “simulate” how people view the sites we build, you're probably better off with a cheap, crappy display that's not adjusted very well …

I only tested Atom very briefly and some time ago, and I don't think I have given Brackets more than a short glance. At first sight, they look and feel very much as if they're trying to be “the better Sublime Text” without really offering (for me, which is totally subjective) any benefit. Instead, I'd have to go through the hassle of configuring a new editor to my liking, which is something ST (again, for me; very subjective) was really good at. My ST config is basically non-existent, I pretty much use it the way it comes. Also, there's modules/plugins – I use only a handful in ST, and I'd have to check if something similar exists for Atom or Brackets.

Bottom line: if you're working with code every day, switching editors is similar to replacing an arm or something. (I sometimes still catch myself using keyboard shortcuts I used in Emacs for about 10 years on Linux.) Despite the (true) facts that ST development is kind of slow and the developer is not very transparent about development, any new editor would still (once again, for me) have to offer really convincing new features to get me to even think about switching.

Yeah, I have completely given up on running local dev servers altogether. The Grunt script includes a small local web server just to be able to server HTML files because sometimes JS won't work properly without a server. As for the whole MAMP/xampp/local Apache thing, I feel it's just not worth the effort. You only end up either having to deal with things that are set up entirely different on the live server or doing duplicate work.

I also don't want to fill up my hard drive with endless local versions of projects (I'm working on a MacBook Air with a rather small SSD, so hard drive space is kind of precious). So if I ever need a staging server (if only to be able to show clients work in progress), I use a dedicated stage on my Uberspace for that. Uberspace is a German web hoster which offers a really neat and convenient server setup including ssh access, so it's very easy to quickly setup a stage there. Of course, that means I can't do some work if I don't have a net connection, but then again, if I don't have that, I usually don't work at all anyway.

I have a project boilerplate that I use in basically any web project these days. It's not specific to PW projects, but can handle those fine just as well (basically by switching from .html to .php files). The quick and simple run-down of what this includes is:

• a set of SCSS files and partials which are not really a CSS framework (I don't like using CSS frameworks) but rather a solid CSS baseline and some extends/mixins, some of them for
• a collection of jQuery plugins and JS snippets that I find myself using time and time again; most of these were chosen because they are developed in a very solid way and available via Bower (I'll get to that in a minute)
• some basic non-HTML/CSS/JS files like a .htaccess, a robots.txt etc.
• some Handlebars/assemble.io layouts and partials, just because generating HTML from Handlebars makes it so much easier to generate static HTML sometimes (i.e. includes for navigations etc.)

A this is handled/tied together by a Grunt build script which takes care of way too many things to list here, but among other things, it takes care of combining and minifying CSS/JS assets, minimizes images, adds vendor prefixes to CSS, generates favicons and more. I usually start any project by building a static HTML prototype because I never learned how to design a web site in Photoshop or something. So even for PW sites, I will first build a small static HTML version, which hopefully covers and showcases all the page types/layouts needed later. That's my base for the PW templates.

Edit: Right, forgot Bower. It's basically a package manager for web assets (mostly JS/jQuery plugins, but not exclusively). Makes it so much easier to keep your JS plugins up to date, I don't even remember how I did that before Bower. Based on node.js like Grunt, so that's required.

For PW projects, I have a bare-bones template, which is just my version of the default template. Similar to the static boilerplate, this already includes some functions and page templates that I know I will use time and time again in projects. Or not. It is also already adapted to the static boilerplate, so it will work with its files and build script out of the box by just exchanging .html files with .php files. (Yes, while I type this I realize that it may not be that easy to understand as I think it is for, well, anyone but me.) Basically, I can just drop the templates files in the static prototype folder, adjust the build script a little and then convert static HTML into PW templates. It will use the same CSS/JS/image assets just fine.

As for modules, as I said in the “your favourite modules” thread, I usually try to only use modules if I actually need them. So, no modules included here.

@yellowled: isn't Language Field Tabs part of the core now?

Yes, you're right: part of the core since 2.4. I only tested it some versions ago, but it was convincing at first sight (which is probably why it's in the core now).