yellowled

Fresh install on PHP 5.4.16 (not sure about the exact Apache 2/MySQL 5 versions, let me know if those would be important). Worked like a charm. Had to explicitly set the RewriteBase to "/", but that's always been necessary on this server. The dev version identifies itself als ProcessWire 2.3.5, is that even the right one? (Downloaded the zip from the dev tree on GitHub.)

It does even offer an SCSS file and a Grunt build script. In my book, that's pretty much perfect. It is also very accessible (e.g. using button for elements which actually are buttons), it seems to offer a fallback to display the content differently on very small screens (where a lightbox really doesn't make any sense) … boy, I wish more jQuery plugins other would be thought-thru that well.

The Magnific Popup caught my eyes as well (haven't had a chance to test it yet, but definitely will). It is done incredibly well, very flexible and customizable and also implemented with an eye for the little things. Definitely a plugin to watch.

Although I know and sort of understand the wish of clients to be able to do so, from a designer's/developer's point of view, these “free form” content types are not necessarily a good choice. (Disclaimer: This might be a very subjective point of view, and yes, I admit to being kind of a control freak.) I don't know what kinds of clients you guys have, but a lot of my projects are websites for people who don't really know much about building web sites. Those clients can actually benefit from a “rigid” approach because it does not only limit their possibilities, it also limits their margin for error, bad layout choices and basically anything which makes designers pull out their hair, as arrogant as that may sound. Then again, as long as this is implemented as a module or an option, keeping the flexibility we all love about PW, this probably is a “why not?” feature. (Just my 2 cents.)

It's funny how CSS layouts haven't really changed over the past couple of years since everybody stopped using table layouts. If you google “css layout types”, it's pretty likely you'll find articles on fixed vs fluid, on responsive, maybe even some on hybrid and elastic. Most of these (responsive being the exception) aren't even about types of layout, but about the dimensions used. (Layout beginner's, don't bother with anything but fluid and responsive.) Also, (probably) the most popular layout technique these days – floats – technically wasn't even meant to be used for layouts. Just like using tables for layouts (Beginners: don't. Just don't.), using floats to align boxes next to each other is actually a hack. But since the new CSS3 modules for layout are far from being usable even in modern browsers (Flexbox and Grids), we're left with what we've been using for years now for the time being – floats and absolute or relative positioning.

Right, there's a “Customize” section on the Bootstrap page. I wasn't aware of that since I never use it.

jQuery is a great example of how a frontend framework can be useful – it makes writing JS way easier (some people would not agree that this is a good thing), takes care of browser issues (unless you use the new jQuery 2.0 and still have to support oldIE) and even makes using JS safer. But it does not impose things on the user like a lot of CSS frameworks do. That is, until you start using jQuery plugins, because some of them require specific CSS to work. The thing with CSS framework is, most of them include a UI component, much like jQuery has jQuery UI (but doesn't bundle it). It would be perfectly okay to use e.g. Bootstrap's layout module, but most people just download the whole thing and use it. (I'm not even sure if you can download just “the good parts”.) So a pretty good indicator for a usable CSS framework would be that it's modularized in a way that you can choose which modules you want to use. If if even has a generator which gives you an individual build, great. But if it is split into modules but still ships the whole nine yards in any download package …

I don't think there's anything to add to kongondo's list. That's pretty impressive. I am not a fan of frameworks, especially not for responsive webdesign. I'm with Teppo here – understanding what's working how and why is very useful, especially if you're not familiar with it yet. Also, keep in mind that while RWD is not limited to mobile/smallscreen devices, they are primary objective. Most framework come with a lot of “baggage”, i.e. stuff that your site won't need. So technically, you'd have to remove a lot of stuff to keep your site slim. Personally, that's now how I like to spend my time … Also, most of these frameworks have kind of a “branding”. I have yet to see a site build with Bootstrap without being able to tell that it's been built with Bootstrap without even looking under the hood. It takes a lot of effort to drop the Bootstrap stuff – I guess that effort would be spent better in actually designing the site …

I always try to avoid absolute or relative positioning unless I actually need it. That's not a judgement, it's just that in my experience, it usually opens Pandora's layout box. I also actually do (almost) every project responsively these days, or at least have it prepared to become responsive. So it's usually a flexible layout using percentage widths and floats or a flexible grid system. Also, I almost always use a mobile-first approach, which means I start with a “non-layout” and work my way up. Simply works better for me with responsive design.

By emitting a newline escape sequence at the end of your echo statement: echo "<link rel='stylesheet' type='text/css' href='{$config->urls->templates}$file' />\n"; For the new line, same thing as above. For the alt text: <?php foreach($page->images as $image) { echo "<img src='$image->url' alt='$image->description'>\n"; } ?> Of course, the proper alt text will only be emitted if you or your editors actually enter an image description in the PW backend. Also, I would advise to emit the images as an unordered list here. That's what they are semantically. You can remove the list bullets using CSS, of course.

You would have Sass (and/or Compass or whatever you prefer) installed and let your Grunt build script's watch task run it for you in the background. For me that's just it: Grunt can do so much more than just run a preprocessor. Yes, it needs some time to get into and get the hang of it, but once you've set up your Grunt tasks, it does practically everything but write code. And I'm sure the Grunt guys are going to figure that out as well one day.

grab.pw should definitely always point to a zip of the latest stable release. wget http://grab.pw

Well, it's a package manager for OSX. You may have heard of MacPorts, which is similar. Basically, Homebrew makes it easy to install software which is neither included in OSX nor available in the AppStore. For instance, I use it to install (and update) node.js.

Haven't used it, but it looks utterly confusing to me compared to command line git + GitHub web interface.

Not sure. I consider myself to be not very firm with PHP, either. In fact, I have stated on numerous occasions that my PHP knowledge resembles the faculty of speech of a toddler. I never bothered to check out out said profiles/tutorials (because they didn't exist when I first checked out PW), I just started to build an older, smaller site. Maybe it helps that I'm firm with jQuery, after which the PW API is tailored. Along the way, I searched the forums, the API docs and asked very stupid questions. That's how I got to know the basic solutions, the “how to do XY in PW”s, if you will. You definitely do not need to be a PHP wizard to build (basic, at least) sites with PW. Sounds as if you're trying to take on too many things at a time. Try to relax and address one issue at a time. Don't hesitate to ask questions here – as long as you've searched forums and API docs and tried to understand it, no one here will bite your head off for asking questions. Most important of all: it is fun to work with PW. Try to have some fun. Well, very basically said, $page is the “currently addressed” page, and $pages is an array (something similar to a list) of pages in your site. You can “modify” that list of pages by using selectors to “limit” the selection of pages you would like to work with.

Yeah, there's always the looming question „How many pages actually have similar content in both (or all) languages?“. I guess there really is no ballpark for this question … anyway, this multilang core functionality is another option, which is always great.

Ryan, what is your threshold for “simple” here? I'm about to port a bilingual site to PW, but there is some wiggle room as to when it's due, so I could wait for 2.3. The possibility of core multilingualism sounds appealing, although I have also managed to set up a test site using LanguageLocalizedURL. But it does involve some work, which I might want to skip here since this is kind of a pet project. So, any rules of thumb as to when to use what?

How about using the Redirect module instead?

Also don't forget that once the (relatively small) “market” of developers and designers is “exceeded”, the term “content management framework” is pretty useless. After that, the market to target is “end users, which are not devs/designers”, and those are very unlikely to look for anything else than a “content management system”. That's the term they know.

I have actually implemented two projects with Perch before switching to ProcessWire. It is probably not as easy to add PW to a site which exists as a static HTML prototype as it is with Perch. That is something Perch does exceptionally well. Here comes the “but”: as long as the site you're maintaining with it stays really small and not too complicated, it is perfectly fine for it. If the site grows and gets more complex (and most sites tend to do that over time), the effort you have to put into it with Perch grows as well, although I have to stress that this is my personal impression. I really don't mean to talk down or belittle Perch. If you and your users like it and it fits your needs, it is probably the right choice. But if this is a site which is likely to grow more complex, it might be easier to go with a CMS which (again: just in my opinion) can handle bigger sites better.

Okay, committed. Thanks a lot, Manfred. Haven't really gotten around to spending much time on the translation lately. Then again, I always meant for it to be a community effort.

Nevermind, got it sorted out a bit already. Should be in the repo at some time in the next couple of days. But a. If you submit changes in a zip again, please, please only include files you actually changed. Thanks. b. Have a look at GitHub. It is pretty easy and a lot less painful.

I beg to differ. First of all, I would set that “Processwire-Seite”, but I really prefer “Webseite” or “Website” (untranslated). (Honestly, I don't really care as long as it's not “Homepage”.)

It's a pull request, and yes, that would be the preferred way to contribute to the German translation. Manfred, if you can't do a pull request or are not sure about how to do that, please let me know and I'll work this in manually.

Just tested this with a test installation which basically runs the Skyscrapers profile. (I use it for playing around with admin themes a little.) Upgrade from 2.2.9 to 2.3-dev running on Apache 2.2 and PHP 5.3.17. No issues.