teppo

@Zahari: you're not alone with these problems -- just take a look at this thread if you haven't already. I have to agree that PW can be a bit intimidating, especially if you're coming from a system with very different concepts in play For me two main reasons PW made sense right away were that it was all PHP and the API really feels a lot like jQuery, my go-to JS library for doing.. well, anything. At the moment I'm learning AngularJS, which is totally different from jQuery and I'm having similar issues: even as it sometimes feels really awesome ("what the.. I just changed this model here and that UI element there updated by itself.. way cool!") other times it just frustrates the heck out of me, especially when trying to stick with the "AngularJS way" ("where's that bloody .on() when I need it?") I used WP for a long time for building blogs and very simple websites. For that it was awesome, but had I ever been asked to do something more complex with it I'd have been really worried. What I like about PW is that it is much more like a framework that can be used to do anything than out-of-the-box super-polished CMS that does X very well. If you just want to do one specific thing, such as build a blog, consider starting with a specific site profile instead. One thing that always makes me flinch when I hear people talking about WP is it's notorious reputation when it comes to security. Being popular and having WP's feature set (registration, commenting etc.) doesn't really help, but excuses like that only go so far. I've seen whole servers compromised simply because someone forgot to upgrade an old WP installation or to follow those mile-long guides on how to make your default installation secure. Security should be built-in, not something optional or -- even worse -- something that users are tasked to implement themselves. That's just bad design no matter how you look at it. Edit: @Zahari, you mentioned seeing some "missing blocks" you'd find useful in the docs. Care to elaborate that a bit further -- what are these missing things? Is it something we could possibly add there?

It's smart to consider continuity. A website is going to cost considerable amount of money and you'll want to be sure that this money is well spent. This is an issue I haven't had to deal much myself, always having worked with a company with somewhat respectable lifespan and status, but admittedly this can be problematic for smaller and younger companies -- freelancers etc. even more so. Personally I believe the country-specific PW sites (de.processwire.com, upcoming italian site etc.) to be of critical importance here. Easiest way to tackle these worries is by pointing out that there are many qualified professionals around and their numbers are growing. It's important to know that you've got a safety net in case that things go wrong. The more people start hearing of ProcessWire, the more they'll start trusting it. It's much easier to go with something you've heard at least a few mentions here and there instead of this quirky new system your somewhat nerdy developer seems to love. (Not trying to dismiss the fact that PW is definitely easy to learn, just saying that it's not a claim that all clients can reliably confirm and thus they should be a bit wary of claims like that.) I'm a "webbuilder" working for a webdesign company and I use PW. Just like Pete said, many of these companies are relatively small, can move quite fast if they want to and perhaps most importantly it'd be foolish to dismiss a tool that can both save a lot of work (and by "work" I mean "money") and improve the quality of your work simultaneously. One motivated developer can often make a huge difference when it comes to a companies choice of tools. Around here many web design companies still use their own, custom-built, closed source tools. What was once considered a "best practice" seems to make less and less sense these days: can you imagine the costs of keeping up and running and also developing further a system that no-one outside of your company knows or can touch? Especially compared to the option of using an open source system like ProcessWire, where a lot of development comes outside of your company, that's often just bad business. I wouldn't be too surprised if more companies started looking for alternatives in the near future and that is an opportunity for ProcessWire: it's unbelievably versatile, efficient and cost of learning to develop with it is a tiny fraction of what some other systems would definitely require. It's a great deal.

Unless something has changed since then, it would appear that this can't be changed that easily. See this thread for a possible solution and Ryan's explanation.

Thanks for all the feedback folks.. your comments (and helpful tips) are very much appreciated! Yes, logo looks just about right there Thanks for spotting the ToC issue. Headers are given IDs on the fly with JavaScript, which is probably why they didn't show up (if you viewed via page source), but there was a very real issue here: While in other browsers (well, at least in Chrome..) you scroll the document <body> to certain point, in Firefox that scroll needs to be pointed at <html>. No idea which implementation is correct (if there even is such a thing), but changing $('body').animate(...) to $('body, html').animate(...) seems to fix it for FF. Those boxes used to have borders and badge positioning worked better back then (see screenshot below -- this is a bit off though, especially padding looks weird as I've just temporarily enabled the borders.) Anyway, I'm starting to really agree with you here. Will have to experiment a bit with these. Thanks for the idea of no-screenshot thumbnail, this sounds like a valid solution.. or I could just try to come up with a thumbnail for all of them, even though in some cases it makes little sense. Also thanks for the iPhone feedback.. I've only got Android phones on me and haven't had a chance to test properly with any iProducts Looks like the GitHub plugin got kind of messed up there. Thanks for spotting this

I'd be very happy if you could do that -- would love to explore this concept a bit further and method I've posted here is nowhere close to "clean"..

Thanks, Adam! Typography was very much a result of trial and error, so I'm glad at least part of it works as intended. I'm a big fan of readability myself and really wanted this site to be more about readability (and usability) than eye candy. Home page started out very different and especially those over-the-place badges are a remnant of a very different style. I'll think about what to do with them, you're quite right about them being a bit off. Masonry I quite like, though you're again right in that it doesn't really make that much sense here.. admittedly it's partly there just because it was fun, but also because it makes things feel "more alive"

It's my first post in this area and this barely validates as a "showcase case", but: I've finally managed to update my own Web presence, resulting in flamingruby.com. It's primarily a blog, but some of my projects are on display there too. This site has actually been up for months already -- wasn't going to post it here, but thought it'd be nice to prove that I've actually built something with PW after all.. Being responsive is fairly standard stuff these days. In this case no frameworks were involved, though; it's all hand-made, built from mobile first perspective and based on content alone, instead of predefined breakpoints. Some details I'm still not happy about, so it'll probably get tweaked every now and then, but at the moment things are pretty much in a stable state. Since it's a personal project, I've been slowly adding small tricks here and there, none of which really count as anything "special." One addition made just today, mostly as a proof-of-concept, is a combination of a simple module and new subdomain (static.flamingruby.com) to automatically serve assets from (at least in theory) cookie-free location. This is described in more detail here. For home page I built an importer module (with AngularJS GUI, which was actually quite fun) that periodically pulls content from various feeds.. a bit like what Nico did with his social timeline, but nowhere as cool as that. At the moment content is being pulled from GitHub (for which I had to put together MarkupLoadAtom) and Twitter (which kindly killed it's RSS support just in time, so I'm using rssitfor.me instead.. although that site interestingly spits out Atom and not RSS like one would expect.) That's just about it.

Have you tried adding "template" there? Works for me already. Doesn't look exactly like what you posted above, though, more like this: About us, template-a 3 | edit | view | new | move Our Board, template-b | edit | view | new | move (etc.)

This doesn't really seem related, though stranger things have happened. Anyway, if you haven't already tried that, empty your browser history -- this has caused us and our clients similar issues (constantly logging out) in the past. If that doesn't help we'll just have to figure out something else

@Gabi: this sounded like an interesting idea, so I mocked up a proof-of-concept module (Page Render Relocate Assets) that dynamically alters asset requests to point to another location. This isn't, however, something you should yet consider production-ready. Idea is quite simple: the module just hooks after page render and alters generated markup, converting any requests to /site/assets/ to another URL specified via module settings. Just to be on the safe side this (at the moment) only alters requests that start with a double quote and /site/assets, ie. "... src="/site/assets/..." would get replaced, while "Look at my /site/assets/!" or "... src="http://example.com/site/assets/..." wouldn't. To test this I created a new subdomain and pointed it to my own sites /site/assets/. According to this blog post this should be enough, and so far things seem to work just fine. You can see it in action here: http://www.flamingruby.com/about/. Note that one of the images on that page is (for some CKEditor-related reason) embedded with full URL and thus doesn't get "relocated", but other one (the bike) should point to static.flamingruby.com instead. .. so to answer to your question here: changing assets location would require a lot of work at the moment, but this way you can serve them without useless cookies etc. as long as that's what you're after. If you're looking to share the load between multiple servers or something like that, this alone won't do the trick (though if combined with some kind of server-side replication that would be quite possible too.) I might have to take this module a bit further at some point, I'm kind of starting to like where this is going

Just to make sure: you're running Windows? Which PHP version? Based on some quick Googling, this sounds like a Win + PHP issue, reported in various places and affecting (at least some revisions of) PHP 5.3 and even 5.4. Edit: only place where PW uses mcrypt_create_iv() is Password.php, to generate random base64 strings for salts. If you're in a hurry, you could try commenting out that whole block (lines 160..163), but after that you really should make sure that this method still provides sensible output. I'm not too familiar with what's happening there, so I'd still suggest that you either try to fix this somehow else or at least wait for someone who knows better to step in and help with this.

Direct quote from Ryan, taken from the first thread linked up there: So yes, that's how it works. Taking a quick look at source, when asked for a database query Datetime fieldtype simply converts selector value to date with format 'Y-m-d H:i:s', right after sanitizing it (in which process any non-timestamp value is parsed by strtotime()). Digging through PW source is actually fun.. and also the only way to be 100% sure what's really going on and what kind of values will work

Sorry for that -- for some reason I simply copied your original (non-working) selectors and didn't fix them for my examples..

What @arjen said + your first example doesn't really do anything: <a href='<?php $pages->get("/gallery/")->url; ?>'> Back </a> Second example is OK (except for the non-working selector), but what you probably meant to do in your first example was one of these: <a href='<?php echo $pages->get("/gallery/")->url; ?>'> Back </a> <a href='<?=$pages->get("/gallery/")->url?>'> Back </a> (ie. you were missing an echo or short echo statement there.) edit: fixed broken selectors to avoid confusion..

@adrian: I must admit that your approach is unique, to say the least. I've never really seen domdocument in action, so this is quite fascinating For a slightly different approach I've just pushed an old textformatter module I never ended up using or completely finishing (JS approach felt better after all) to GitHub: https://github.com/teppokoivula/TextformatterImageWrapper. This was intended just for wrapping images with a div element to enable more flexible styling, but also has an option for appending the description within said wrapper (which seems to be the topic of discussion here.) It's very much a work in progress / beta / proof of concept, but should be fully functional already

First thing you should always do when having problems is checking your error logs, both for PW (site/assets/logs/errors.txt) and Apache (usually /var/log/apache2/error.log.) Does anything show up there when this error occurs?

This won't help much with your current issue, but I've just pushed new version of this module to GitHub. This version adds an option to log which script triggered (ie. initiated) each action; a path or an URL, depending whether context was HTTP or non-HTTP. This feature can be enabled via settings of Process Changelog Hooks module to either external scripts only or both external and local scripts (ie. current PW installation called in "normal way" -- bootstrap method is considered "external.") Haven't been able to test it thoroughly enough yet, but so far it seems to work. If anyone has time to test this, I'd love to get some feedback.

Most of default content points (created_users_id DB field in pages table) to page ID 2, which is the /processwire/ page. This seems like a sensible solution to me.. even though /processwire/ obviously isn't real "user" either Edit: taking another look at that quote, I'd like to add that having user specific to bootstrapped scripts would be great. At least for those of us who use these quite a lot, it would help keeping track of things.

Some people probably prefer to have more (and more specific) field types, while others (like me) prefer more basic building blocks that can be combined on case-by-case basis to make hyperlinks or whatever else is needed. Repeaters are a great way to achieve this.