teppo

I'm developing a module that lets user specify which fields she wants to show in the result list (which is intended for print use, but that's not very relevant here.) My problem is that when multiple fields are selected SQL queries tend to pile up which results in sluggish page load times. Currently matching pages (selector is also generated based on user input, but that's another story) are loaded with $pages->find() and then looped through with foreach and rest of the fields (which, as I mentioned above, are actually chosen by user) are fetched individually. This is where things get really slow, especially if user has specified 10+ fields to show One solution I've used to make things a bit faster is that most commonly used fields have autojoin setting on and thus PW doesn't require another query to fetch their content. Problem with this is that same data is used elsewhere in simple list views, which get way more hits than my little module here does and if I make all the fields autojoin it would seriously cripple those other views and in the long run possibly suffocate whole server.. Long story short, what I'm looking for is a way to turn on autojoin for certain fields on the fly before fetching pages OR mimic similar feature some other way. Any ideas how to achieve something like this are more than welcome - and don't hesitate to tell me that I'm doing it all wrong, if you know a better way to achieve same results..

I've always been fascinated by Ruby and wanted to learn more of it. As a language it's super clean and contains many little "tricks" you can use to write really beautiful code. On the other hand, I've always been held back by the fact that even though Ruby might be pretty, it's not particularly powerful / efficient and definitely not nearly as well supported and widely adopted as PHP. When using Ruby to build web-based applications the only available (and viable) solution seems to be Rails. Someone correct me if I'm wrong -- other solutions do exist but generally speaking they don't seem mature enough to use outside small / personal projects. Meanwhile with PHP there are quite literally hundreds of viable platform choices. Anyway, widening your toolbox with things like Ruby/RoR sounds like a great idea, but I sure hope your employer doesn't force you to use RoR for projects it doesn't really fit just because it's "hip" ('cause that'd be a real shame )

Looks fantastic. Thanks Pete!

Actually same problem @apeisa mentioned happened to me too. Thought it was just a one-time quirk, so I didn't mention it before. Seems that when page is loaded for first time (when animation / it's components aren't cached yet) the animation won't show up at all.

@apeisa: yeah, well, MediaWiki takes some getting used to.. once you "get it" you'll realize that it's super powerful (but still rather confusing at times.) Wikipedia is actually using a newer, cleaner and much easier text editor these days. It has most of the basic formatting you'll need (such as different headings, lists, refs, tables and blockquotes etc.) implemented in an easy-to-understand way. Might be worth taking a look at, perhaps we could have that one too. Edit: the text editor that Wikipedia currently uses can be found from here: http://www.mediawiki.org/wiki/Extension:WikiEditor.

@Gazley, to answer your original question: I don't think that there are too many proper tutorials on module development available. At least I haven't seen any, so please, someone correct me if I'm wrong There has been some talk about proper module development documentation and/or tutorial though, see this topic for an instance. In my humble opinion that's something the community definitely needs at some point, preferably rather soon, because (IMHO) asking the same questions over and over or trying to dig all the tips from dozens, hundreds or even thousands of posts is not very efficient in the long run. Of course many of us like to learn from examples, but I'd still prefer to have common guidelines, frequent questions / problems, basic components and things like that explained in one place -- this would make it much easier for new folks to get into PW module development. Anyway, once you've managed to grasp basics of module development, why don't you share your tips for others too? wiki.processwire.com would be a great place for such content.

I don't want to sound too strange, but I've been watching that header animation for almost ten minutes now. With inspect tools opened. Drooling a bit. Absolutely brilliant stuff! Oh, and the rest of the site is very nice too

Highest page count I've seen on a production site so far is 30k+ and that site runs just fine. All things considered I wouldn't be too worried -- PW is surprisingly resilient There's an earlier thread with almost the same question that you really should read; in his reply Ryan explains some of the things you need to consider when building a (very) large site: http://processwire.com/talk/topic/1527-largest-project-performance-multi-server/#entry13779. That performance issue Soma mentioned is discussed further here: http://processwire.com/talk/topic/1508-performance-problem-possibly-a-bug-in-pages-class/ (and yes, related problem / bottleneck has already been fixed.)

Should've known it: only editor you'll ever need my editor of choice already has solid support for SASS / SCSS: http://www.emacswiki.../emacs/ScssMode. Another reason to give it a try. That's actually exactly what I was talking about earlier. I can't help feeling that stylesheets should be as simple and "dumb" as possible to serve their original purpose, which IMHO is to provide separation of concerns; HTML for structure, CSS for style (presentation) and server-side scripts / programming (PHP, Perl, Ruby / Rails etc.) + Javascript / ECMAScript for logic. All these features being added by SASS, LESS and even vanilla CSS3 (transitions, transformations, animation, media queries, variables..) are -- no matter how useful they may be -- constantly taking it further down the road to becoming less (no pun intended) of a presentation / styling language and more of a "lightweight programming language" -- and that's definitely not something I'm happy about.

First of all, 0x100 version is a thumbnail created by either size(), width() or height() calls in your templates or possibly by admin (if you've chosen to show thumbnails for that image field.) Secondly, I'm assuming that your image field is called "images" and it can contain multiple images? It sounds like you're asking the field itself for an URL when you should be asking that from an individual image: echo $repeater->images->eq(0)->url; Or you could loop through all the images: foreach ($repeater->images as $image) { echo $image->url . "<br />"; } Edit: Soma was faster -- again

@yellowled: thanks for your patience and explanations. You have definitely persuaded me to at least give SASS a fair chance. Not saying that I'm still completely convinced, we'll just have to see how well that goes. @apeisa: you're saying some things that I find a bit worrying (I love organized content and that concerns stylesheets too.. which is probably one of the reasons why SASS / LESS sound so tempting to me) but for the most part I believe that I share your view here. New features must prove their value before going into production, so to speak. Bad metaphor, but I hope you get my point

It's about the fact that we're developing solutions in our own environment where we have to consider long term performance, reliability, scalability and maintainability of every new solution we implement and mainly because of that I'm always very conservative when it comes to implementing anything that I don't consider "necessary" or (at least) "very advantageous." Everything we implement also has to support team work properly -- thus "write SASS / LESS code locally, compile and move to remote host" method is pretty much out of consideration. There are various other things to consider too, but the main point here is that I'm not comfortable implementing anything new without knowing thoroughly what it does, how it does it and what are the benefits / costs involved (and in my humble opinion there are very few web-related techniques with no costs at all) Edit: just wanted to clarify that while things like that mixin you posted definitely are neat, I would still argue that compared to raw CSS they are more complex and thus require more effort (which is multiplied if neat tricks like that are used on a regular basis) especially if you're not too familiar with SASS syntax -- thus they would need to provide some very real extra value to be considered "worth it." My point here is that just looking cool isn't always enough. I know that I'm being somewhat uptight here though, sorry for that This is exactly what I'm worried about, quite possibly because I just don't know SASS / Compass well enough and SASS documentation isn't very helpful. They did mention that I can run sass with --watch param (I think it was something like that anyway) but what does it actually do -- is sass going to run as a background process and grab any .sass / .scss files that have changed automagically, or..? If that's the case, then this sounds easier than I expected I was aware of this and this is not such a huge problem really, though it's still something to consider if I did (and I can't imagine any reason not to) use SASS-specific syntax. Everyone else would also have to learn at least the basics so that they'll know what to do when things need to be changed -- not that it would be difficult to learn, but still. In environments heavily relying on team work you just don't go changing stuff / implementing new technologies without discussing it properly with other members of the team. That's actually a shame, since this is one of the reasons why I've considered SASS / LESS so beautiful. Nesting FTW

@yellowled, I think you've proven your point; that looks really neat and (even better) re-usable. That said, I'm still not 100% sure that this is something we need enough to justify the hassle involved. I'm painfully aware of the fact that most developers are always tempted to make everything look and feel cool and re-usable code wise (or markup / stylesheet wise) even if there's very little (or none at all) real, measurable value to be gained. Lately I've been trying to eliminate any and all extra steps in my own work -- as hard as it can sometimes be. Will have to go through some older projects to see just how much trouble this could've saved me though. Hopefully I'll come to the conclusion that it's well worth it, since it really does make things much more beautiful (and to be completely fair I have to add that there's some real value in that already.. )

Just my two cents: First of all, when I first started to get into LESS and SASS, I found LESS documentation more "newbie-friendly" -- or perhaps just "friendly" in general -- and that's a big part of why I was instantly drawn into it instead of SASS. Not the best way to choose your tools, but that's still how it often goes.. The main reason why I haven't used LESS (or SASS/SCSS) in customer projects is that we have multiple people working on same projects, sometimes at the same time, so 1) compiling locally and just uploading a compiled CSS file isn't really an option (I'm not even considering letting JS handle compiling on a production site) and 2) I can't just jump in the LESS/SASS/SCSS bandwagon by myself without discussing it properly with others or I might have some serious explaining to do later on. I do know that LESS can be compiled server-side with the help of Node and now that the PHP version was mentioned (thanks Marty!) I'm likely going to check that one out too, although the final deployment process still requires some thought. Anyway, I'm sad to say this but all the hassle has already made me somewhat cynical about whether we really even need the added complexity and overhead compared to plain old CSS. Is it really THAT difficult to keep pure CSS files up to date? In my experience the answer is "very rarely" and I'm saying this even though I've worked with some seriously bloated relatively big stylesheets before. LESS/SASS/SCSS/whatever are definitely an improvement over plain old CSS, too bad they're not natively supported by browsers but require various tricks and gimmicks to run smoothly. Just saying. Sorry for the rant and sorry for getting sidetracked. This is an interesting subject both in technological and theoretical sense and those always tend to get me on my toes. One of these days I'm definitely going to try LESS on a "large-scale" site just to get a better view whether or not it's really worth it -- until then the rant above pretty much summarizes how I feel By the way: have you guys already seen the W3C draft for CSS Variables? It's not the same thing as these frameworks mentioned here, but it is a small step to the same direction: http://dev.w3.org/csswg/css-variables/.

I do realize that you're suggesting that having the checkbox on the selectable page itself would be better UX wise, but I'd still suggest using a Page field on homepage. This way you can easily allow the user to select only one page AND all required features would already exist -- no need to reinvent the wheel Anyway, if you really want to have that checkbox on each individual page then the module you're suggesting might be the only solution. I'd probably just create a new module and add a hook before Pages save ($this->pages->addHookBefore('save', $this, 'checkFeatured') or something like that) and there (after checking if the value of this checkbox has changed for current page / if current page is a new page and has that checkbox checked etc.) make sure that no other page has the checkbox checked. Edit: Ryan beat me with his answer and pretty much posted the precise code you'd need in the hook I mentioned.. Another option would naturally be allowing multiple featured pages, with some kind of Javascript slideshow enabled to only show one at a time.

This does actually look like a bug to me. If I'm reading this correctly, there should be .. Tab titled Location (location_tab) Inside that fieldset titled Location Description (location_content) which only contains two fields: location_title and location_description All the other fields here should be inside tab Location but outside fieldset Location Description (location_content) What's happening instead is that fieldset Location Description has "swallowed" even those fields it shouldn't contain. Actually I've seen something like this happen previously with similar settings. Can't honestly remember if that was fixed by some random trick (re-adding fieldset, saving template again or something like that) or if I just decided to go with simpler layout. Anyway, would be nice if someone else could confirm if this actually is intended behavior (I very much doubt that) or some odd bug within Admin.

@Pete: seriously, this is what I'd call a great timing! Just a few days ago I pushed my own jQuery placeholder plugin to Github (https://github.com/t...put-placeholder) -- wasn't aware of this one before but it sure seems like something I'll have to take a closer look at. Thanks for the heads-up My plugin does essentially just the same as this one with a few differentiating features. In some ways it's a bit more simplified as I've focused on the particular needs I've encountered in client projects so far, such as need to set specific styling for placeholders etc.