teppo

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.

@NoDice: this sounds like a perfect match for repeaters. First you'll create the fields you need; one URL field for link href ("link"), one text (or textarea, if you need longer texts) for your description texts ("description") and one image field for your slideshow images ("image", limited to one image per field).. and also one repeater field (let's call it "slideshow" for this example) that you'll configure to hold all the fields mentioned here. After that you'll insert the code, which would work just as @diogo mentioned earlier: <?php if (count($page->slideshow)) { echo "<ul>"; foreach ($page->slideshow as $item) { $thumb = $item->image->size(600,250); echo "<li style='background-image: url({$thumb->url})'><a href='{$item->link}'>{$item->description}</a></li>"; } echo "</ul>"; } ?> I'm making some assumptions about what the markup for your slideshow is like, don't worry about that; you should be quite easily able to adapt above example for your specific needs.

@ceberlin: did couple of quick tests and it definitely looks like a) actions ran through Batcher get correctly logged as actions of the user that ran them and b) API actions via bootstrap method always point to Guest user. In your case I'd keep looking for an external script that bootstraps PW and does some changes OR template code that alters content when a visitor loads a page with that template. Front-end edit forms would be potential causes for this too. I have to agree that actions of API pointing to Guest is confusing, but as it's internal PW feature I prefer to keep it like that here too. Reasoning behind this seems to be that when doing something via API, whether triggered by unauthenticated visitor or some external script, you don't actually log in as any real user .. so the real issue here is probably just that "Guest" sounds very odd in this context.

Sorry Adam, I've completely managed to miss this post! And thanks, by the way -- it's good to hear that someone has found this module useful This is a bit late for a reply, but anyway: I wouldn't be too worried about performance impact. There's no heavy lifting happening code-wise, just some hook methods with a bit of relatively simple logic. One extra query (most of the time) for each page save shouldn't do much harm either and since this only happens when saving pages it's definitely not a problem on most pages. On the other hand, if you do find that there's some kind of performance penalty, I'd be happy to check it out and see if things can be further optimized. (I'm sure they can, just haven't found a reason to do that so far.) Only case where I would worry a bit about things getting out of hand would be a site where pages are constantly changed (ie. some public feature triggers page save all the time) and that data gets logged. In a case like that it would make sense to a) not log every action and/or b) limit the time log entries are stored for. I could also add a template setting at some point, so that admin can select which templates require logging in the first place..

Most likely either API usage, or perhaps some internal PW feature.. for these user seems to be "guest", which is a bit confusing to say the least If you're sure that neither of these were the cause, then I'd love to dig in a bit deeper. These are the cases that have triggered changes by "guest" for me in the past.

You probably mean stop words? Seems like a reasonable feature to me, especially if made configurable (as English stop words make very little sense / are sometimes even harmful for a site written in Finnish etc.) Just saying.