yellowled

I love this, it makes 301 redirects really simple. I seem to have found another URL scheme it doesn't support yet, though. "Incoming" URL is /index.php?/pages/bfs_ka.html – when I edit the redirect, it reports an invalid URL in redirect_from.

Wow. That's embarrassing (for me) and even better (for you) at the same time. It indeed behaves very nicely on smaller viewports without a single @media. While I'm looking at the code: If you want to score some performance bonus points, you might want to concatenate javascripts and stylesheets (not with each other, of course), minify the concatenated files which and put all the JS at the bottom. (Disclaimer: Yes, I know there are other ways to boost JS/CSS performance, but this is the most simple one, and it's usually pretty effective.)

You must have mistaken me for a PW developer, which I am most definitely not. This is very neat. I didn't actually realize it's responsive until I resized the browser, which is always a good thing. Sometimes, you can spot that it's responsive from the "desktop" layout. Not with this one.

I have said it before, I will say it again: Markup Simple Navigation rocks! Together with a JS-based redirection to a new tab, this is very close to perfect. Thanks, Soma!

This would have been my first choice since I want to open the new tab using JS anyway, however it doesn't work on those redirected links in the navigation since the href attribute of those is still a local link. The navigation is created using Markup Simple Navigation. For any reference to an external page, I have a template page-redirect.php, which contains just <?php // Internal or external redirects in primary nav if($page->redirect_url) $session->redirect($page->redirect_url); This template only has the fields title and redirect_url. So if I had a page /markup/navigation/ with the redirect_url set to http://processwire.com, the link href in the navigation markup would still be /markup/navigation/. It's redirected after the link is clicked which is why the JS solution won't work. Can I maybe add code to Markup Simple Navigation's item_tpl using template selectors?

I use this (together with a URL field als the only field of a special template) for "external" links in the navigation. Works like a charm. Now the client would like these links to open in a new tab in order to keep their web site open. Any chance to do this with $session->redirect in a sensible way? Obviously, I do not want to use target="_blank".

Not at all, same here. The bookmarks toolbar just takes up too much space on a 1366×768 pixels display.

Wordpress and Contao are examples for what can happen to a CMS (or blog engine), if it gets too many modules or plugins – every tried finding a good contact form or lightbox plugin for WP? Good luck with that. It'll cost you days. Modules are great for non-expert users (which is why a blog system like WP is more likely to have a lot of them than a "real" CMS), and I admit that there are things I couldn't do in PW in a reasonable amount of time without modules. But in case of simple stuff like a lightboxed gallery, I prefer to have a CMS emit the markup I want and use the lightbox script I want instead of using a module which never seems to emit the code you'd want it to. I'm not sure this "module proliferation" is something you can control beyond a certain point of growth of a CMS or blog system. But as long as it's possible, "one module/plugin per purpose" is something a CMS can really benefit from. I would like to see PW's users adapt such a philosophy – if you intend to write a module, first take a look at the existing modules and see if you can extend one instead of adding (maybe duplicated) functionality via a new plugin.

NoDB means that all site content is stored in text files (actually: Markdown files). It works pretty well, but is probably not suited for just any client because they need some way to upload/access said text files on the server, meaning (s)ftp or ssh. I don't know about the average client you guys have, but I couldn't name any previous or current client who would be comfortable using a text editor and/or (s)ftp/ssh, let alone Markdown syntax. Clients, at least that's my experience, want or prefer a web interface and a WYSIWYG editor.

I have kind of lost track on MODx since I discovered PW, but all I'm reading about MODX 3.0 and MODX Cloud doesn't really convince me. It feels like a platform which is technically great is being marketed and maintained in ways which I don't consider "right" for an open source software. There is this little hint of "Yeah, we're open, but in the end we're gonna do it the way we think is right anyway."

Can't really comment on Akismet's accuracy in general since I've never used it myself.

As for Perch, yes, they are doing a great job, not only in presenting their product. Given the fact that it's maintained by two people, Perch is just great, especially in terms of support. However, it's not really suitable for bigger sites as it gets rather complicated to add and handle a large number of editable fields, which are the key ingredient of Perch sites. Still a good option for small sites, especially for clients which are not very experienced in using a CMS. MODx is huge in every aspect. Very powerful, but also very complicated in some areas. Setting up users and permissions is especially painful. It has the "total freedom of markup, CSS and JS" factor, but it also has an ExtJS backend which is anything but fast and lean. In fact, MODx is pretty close to PW in my opinion, but PW makes almost everything which is painful in MODx easier and better. As for Contao, I'm using it in 3 projects, but I won't use it for new projects. I'd still recommend it for non-professionals which are looking for an easy-to-use CMS, but it doesn't work well for me because of the template system and integrated CSS framework. It's just too much work to customize even a fresh install to the point where I can work with it the way I like to do. I get why it's being developed in the direction of a "better Joomla", and it's probably the right choice for their target audience, but I'm just not part of that audience. I haven't really worked much with Drupal. I like it a lot better since v7, but I always feel it's a bit clumsy. You asked for the CMS we'd use if we had to choose something other than PW, that's why I mentioned it – I don't have many reasons not to use it, and the ones I have are probably related to the fact that I don't know it very well. Also probably takes a looong time to get to know it really well, which is something I never had the time or patience to do. That's actually another area which PW won by a landslide. I have rarely gotten accustomed to a CMS that quickly.

If Akismet is working in general, i.e. some comments are properly detected as spam, it just shows that Akismet (like basically all spam filters) isn't perfect. There really is no such thing as a "foul-proof" spam filter. Any mechanism, any test can be circumvented by spam bots.

I have used a lot of CMS in the past, but it seems I have developed a very special taste which narrows down the list of candidates pretty quickly. If the CMS generates markup, it has to be editable. Easily. Preferably it has a "no default markup mode" or something. Markup's my job. If the CMS has templates, they should have a physical representation, i.e. template files, not just templates stored in the DB. If I can't edit it with my favorite editor, it's not a template. If the CMS comes with a CSS framework, it has to have an option to disable that framework. I want to be able to use "my" CSS. If the CMS uses a default JS library in the frontend, it better be jQuery. I don't care what you use in the backend, but I don't get MooTools and all that other stuff. If you use ExtJS, you're out. It's slooooow. Open Source only. Paying a suitable fee is okay, but you better let me have a look at your code. That being said, I have seriously evaluated, tried and use(d) MODx, Contao, Drupal, Perch and ProcessWire over the last 2 years or something. (I don't count blog systems as CMS, not even Wordpress. If I need a blog engine, I use Serendipity.) MODx, Contao and Perch all either collide with one or more of the 5 points above and/or have made some weird development or license choices I don't like. So I guess if I had to use another CMS, I'd go with Drupal. (I hope I never have to, though.)

What I probably love the most about it: it's built using Twitter Bootstrap and it doesn't show. There are a lot of sites using Twitter Bootstrap out there on which you can identify the framework at first glance. That alone is a really good job. (Which doesn't mean the rest of the site isn't done well or something, it's just what strikes me most about it.)

Beware that it might be a bit more work if you develop in a subdirectory locally but transfer it to the root directory on the remote server. Wasn't there a module to make that easier? Page Link Abstractor?

Hey, it got me (who never got his mind around PHP in various attempts), into learning about strftime, strtotime, date and all that stuff this morning. So thanks PW for teaching me yet another lesson in PHP. Watch your backs, I might take the whole thing over some time.

Seems like he dropped it. I was worried it could be the server since I have to work on a server by a German webhoster which is known to be quirky, but I don't get the unix timestamp option on my local server with the new version, either.

Hmmm. In the "live version" on the server, I can't select "unix timestamp" as an output format in datetime fields. On my local dev server (with patch applied) I can. Live version is today's github snapshot. Is this related to that or am I missing something here?

Ryan, just to make sure: did you commit this to the core so that your datetime patch is no longer require in current PW versions?

I think it really depends on the kind of beginner you have in mind. Someone who knows HTML farely well and maybe has some idea of programming (let's say through JS), but no PHP knowledge might actually like something like i.e. Smarty. For someone with no programming experience, but willing to learn, it might not make a difference at all. In my experience, what "scares" people about pure PHP templating is the syntax. It's pretty close to HTML, but introduces some things they usually don't have to deal with in pure HTML like single/double quotes, special characters etc. Most template engines use a syntax which is easier to distinguish from plain HTML at first glance. That's what "comforts" them. Bottom line, as long as it's optional, a template engine might indeed attract more users without driving away the PHP-only folks. But beware – it might as well become Pandora's box. You add one template engine, people want another one …

Ah. Lost in documentation. Thanks!

For a chronological news archive, I use url segments to emit news listings per year – …/2012, …/2011 etc. The template creates a list of years for which the site actually has news posts in store, but of course, users might get the idea to edit the url segment manually, i.e. enter something like …/1974 in the browser's address bar. The template covers this by emitting a "no news available" message, but I'd rather it would throw a 404 for future years and years without posts. The "check if the url segment matches a year which makes sense" part I got down, but how do I trigger a 404 manually? (Please excuse me if this has been covered before, but "url" and "404" make this kind of hard to search for due to the 3-letter search terms. )

I second that. Since I'm involved in another open source project which actually uses Smarty, I have been working with Smarty for some years now. I still like it because it saves me from having to do "actual" coding – Process Wire's API does just the same, but offers more flexibility and possibilities.

And again, with PW, it's just too easy. Perfect, thanks a lot.