yellowled

Matthias Mees - Eutin/Schleswig-Holstein - http://netzgestaltung.net Nico, if you need any help building that German site, translating or writing or whatever, just say the word.

It's funny how rather simple means often seem to work pretty well in terms of avoiding spam. I don't know if the comment form in Textpattern still works the way it used to by default. It simply did not emit a submit button at first, but a preview button. Once you hit preview, the preview button turns into a submit button, enabling you to submit your comment. And since spam bots can't click …

No captchas anywhere, at least no visible ones. They're usually inaccessible, not as “bulletproof” as many people may think, and a nuisance to any visitor. Ever spent half an hour entering whatever you got from those stupid captcha images, failing over and over again although you were sure to have entered the correct pass phrase? Exactly. There is no perfect solution to avoid comment or contact form spam. As soon as you offer any kind of contact via form, you're going to get spam, period. I have found that a hidden captcha/honey pot can work pretty well and avoid a lot of spam. That basically means a hidden text input field which is not supposed to be filled out and is hidden via CSS from visual browsers and screen readers. Spam bots tend to fill out said field anyway, which means the PHP logic of the form will not send it. Of course, at some point, spam bot will adapt to that as well … YL

Depends. Here's an example: I'm involved in the development of the Serendipity blog engine. While it's not technically a German project at all, our lead developer (“our Ryan”) is German, as are most of the contributing devs. Since Serendipity also has a lot of German users, it seemed reasonable to set up a German-only subforum on the user forum for those of them who are not confident in their English skills. So now we have quite a few German-only forum threads which “hide” valuable info from people who don't read German, although we usually encourage anyone to use the English subforums if at all possible. So while I think that a certain amount of local activity can be a good thing - basic localized information/documentation, a list of local users/developers etc. -, too much local activity can also lead to a fragmentation of the community. I would, e.g. not necessarily consider a “German PW forum” a good idea. Also, localized documentation is kind of cutting it both ways - while it's a good thing for people who don't read English properly, it is very hard to keep localized docs up to date. Just my 2 cents, though.

Lovely idea, Nico. Of course, the W-community still has other German sites since they're heavily organized (yes, Germans also love to join clubs and organizations!). But as kind of an official ”yes, PW also works in German and there are German people who know what they're doing and use it“ site, this would be perfect, especially since it scales. There could be fr.processwire.org, fi.processwire.org etc. And if someone would want to create an “inofficial” PW community site, they could still use a different domain for that.

Translation of the German text on said site for the non-German guys: Jeez. I mean, if you're gonna block a domain, just have the decency to put some content on there. What's wrong with a cat GIF? As for the German community site's name, I think “pw[something]” is too generic. This could lead to legal issues (yes, Germans love their legal issues). I don't see what's wrong with processwire-cms.de, but of course, it's your call.

I used to do the same thing with two Linux machines and used Unison to keep them synced. However, you'd (probably, unless you get static IPs for both machines) have to have both machines in the same network to be able to sync them. Unison is (I think) discontinued, but it's pretty stable. Also, Cubby sounds way more convenient.

My setup's pretty similar to Nico's. Since I'm travelling quite a bit, I went for a 13" MacBook Air recently. Since I don't run Creative Suite or similar apps and do most of my work in a text editor these days, its performance is more than sufficient. Excellent keyboard and trackpad for my taste, I don't even use external ones at home. I do have a larger monitor there (24" Samsung), which I prefer to use in multi-monitor mode. However, that really gets the MBA's fan running after a few hours.

As to why Markdown is so popular: I think it's got a lot to do with GitHub using Markdown. GitHub is so incredibly popular among web developers that you almost have to know Markdown. Also, iA Writer uses Markdown, and that's a pretty popular Mac/iOS app. It also tends to (but that might be just my impression) be a bit more robust towards irritations in the syntax than Textile. For example, you can easily produce markup errors in Textile by using emoticons with “noses” in Textile. I have never experienced those in Markdown. Again, this might be a rather personal experience.

Thanks, soma. (This is so great. One could probably even expand this to check the images for size before resizing them. No, don't tell me how, I want to find out myself.)

Well, obviously. But I didn't think of that when I built one particular site, which unfortunately happens to have quite a lot of images. And most of them are being uploaded directly from digital cameras … Technically, it probably doesn't make a lot of sense to purge the originals. Let's say I changed the thumbnail sizes in the template. In that case, resizing the thumbnails would fail because the originals was no longer available.

I usually use $item->size() wherever possible to make sure clients don't put huge images in pages. However, even so, the uploaded original image remains in /site/assets/files/, potentially taking up a lot of webspace. And I guess we all have had clients who just couldn't bet bothered to resize their digital photos before uploading them. Once proper thumbnails are generated in PW, is it safe to delete the original file? And if so, could this maybe be automated in some way? (I don't dare dreaming of a module for this …)

This is not specific to PW projects, I would use the same approach or techniques for plain HTML sites or projects with a blog system. This is because I always start with an HTML prototype which later is converted into a PW template. I actually have … well, I wouldn't call it a framework, but a “starting point”, a boilerplate. This is derived from the HTML5 Boilerplate and combined with some basic CSS and JS stuff. Just some reliable CSS (see later) snippets and jQuery plugins I use often or all the time. Having (and knowing) that helps a lot, but beware - it can result in repeating yourself in your designs. I also have a (small, but growing) collection of PW snippets, most of them stripped from the default page profile or used in projects. (Also saves me having to look it up in the forum again.) Two other things which have really helped me to save time … well, it's not so much about actually saving time, but more about saving nerves by not having to manually do things … anyway, it's using a CSS preprocessor (I prefer Sass/Compass, but I honestly think it doesn't make a big difference if you prefer LESS or Stylus) and a build process to automate things (I have recently switched to a Grunt-based build system, but other build scripts should work just as good) like combine/minify CSS/JS, optimize images etc.

I used to work with a CMS which bundled MooTools in the frontend by default, kind of forcing users to use it, which I always thought was a very bad choice. I never really got MooTools, but that's probably because I kind of learned JS through jQuery. Some JS ninjas out there seem to prefer MooTools over jQuery, however. It's way leaner than jQuery, which is nice, but there are even leaner JS “micro libraries” now. What I really prefer in a JS library is a wide choice of plugins for various solutions, and those don't seem to exist for MooTools, at least not to the extent in which they exist for jQuery.

God, I hope they build a better preview for this and add non-JS ways to include the fonts … font selection seems to be much nicer than in Google webfonts.

You're right - ultimately, everything in PW is a page. Think of a page as a combination of a template (which controls the way said page is emitted in the frontend) and fields (which control which data said page has access to, although there are ways to access data of fields other pages use as well). (This, of course, is a pretty simplified version of what a page can be in PW.) For your client to add a new wine, he'd have to create a new page using i.e. the template ”wine” which could (this might be just one of the many ways of implementing this in PW) hold all the fields to store properties of the different kinds of wine. But there are many different types of fields available in PW to make this process maybe much easier than you'd first think. For instance, the varietals could simply be a select box which offers a limited selection of varietals to be selected in the backend.

Oh well, haven't we all? I know, and people in our line of work also tend to prefer criticism over praise for whatever reasons. The list would have to be discussed and curated in some way. To make that clear: I could just as well name two or three German hosting companies which do a very good job and would be suitable for PW hosting, although I have only installed PW on webspace provided by one of them.

Just an idea: As long as it doesn't clash with the ServInt ad on it, maybe processwire.com could feature a list of hosting providers suited/recommended for PW? This could be sorted/sortable by countries. I'm sure we have PW users in at least the bigger countries all over the world now who could come up with recommendations for hosting. (I know I could name one from Germany which people should not use, but we probably do not want those listed on processwire.com.)

Appreciate the effort, but the repo already has ThrottleLogin, which translates the same lang variables (but a bit differently, of course)?

That's the point I totally agree with. Andy Clarke tweeted - quite some time ago - “From now on, if it's not responsive, it's not web design.” That's just it. It shouldn't be special to build a responsive site, it should be the default. Responsive design can be so much more than just optimizing site for smartphones and tablets. Likewise, “responsive” should not be a feature worth mentioning for a piece of software like a lightbox. It should be the default (which it is for some lightbox scripts).

Yay, a responsive lightbox, but the demo site for it is not responsive. That makes a lot of sense. I've always wondered why one would need a “responsive lightbox”. Might be related to the fact that I haven't used anything but Colorbox in a while, but most lightbox scripts allow you to set the width and height of the lightbox to a precentage of the screen, which usually does the trick for responsive layouts. If the lightbox script doesn't use images for it's design (which would be a no-go for me these days anyway) but is CSS-only, this should suffice. The only limit should be the physical dimensions of the image in the lightbox. Then there's smaller screens. What's the point of even having a lightbox on mobile device where the lightbox image likely isn't much larger than the thumbnail because of screen real estate? And even if so, does the lightbox cater to the smaller screen by displaying the controls etc. differently? (Fresco actually does work pretty well on small screens.) Maybe I'm missing the point here, but “responsive lightbox” sounds a lot like buzzword bingo to me … especially since it offers a paid “pro” version.

OT Funny thing: in German, you compare apples and pears as well (if I get this right from Dutch).

Does help you solve this?

I've been using a lot of icon fonts lately, http://fontello.com/ is just perfect for that. Other than that, I've always adored Paul Robert Lloyd's social media icons, also because of the amount of services it covers. A lot of social icons sets look great but only have icons for a few services. Not this one.

Another small site relaunched with PW. It's a local one-man event management business. http://www.kreativkonkret.de "Non-design", which the client prefers. HTML5, responsive, using a customized Google Map as well as a (rather well hidden) customized lightbox. The home page is supposed to always fetch the next upcoming event from the events page ("Veranstaltungen") if event dates are entered properly (and if I didn't screw up the template logic for that). Also, this is the first live site in which I've used Pete's Minify module to deliver minified and concatenated CSS and JS.