teppo

First of all, everything about this site is simply gorgeous. Awesome work! As a downside (since there always has to be at least one of those) it's also rather sluggish; especially those images at the top of the page (frontpage is worst, but ones on subpages too) took ages to load, which kind of hurts the whole user experience. Then again, this is coming from a user who's currently viewing your site through slow VPN connection. Worst case scenario, you could say. Anyway, the site really is so awesome that it's sluggishness is almost forgivable. I'd still consider cutting some image quality to reduce file size and improve loading times (and thus UX) especially for users with slow connections

So, to put it short you're trying to create new admin area where admins can create new users? Why can't you just give them access to PW users page in admin, or am I missing something here? If you'd provide a bit more background info I might be able to provide more helpful response.. Anyway, if you wish to create users with your own code, you should first check out examples on $user page. At the bottom of that page you can find a simple example for creating new user. And for allowing users access to certain pages they're not usually allowed to view, this post by Soma could be helpful -- what he's doing there is giving users edit access to pages, but that code could quite easily be converted to only allow view access.

Minor misunderstanding: when you said "I cannot simply put the .php file in the styles folder and include it in my templates", I thought you meant "include" literally -- using PHP include(), that is. Sorry, my mistake. Anyway, including content of style.php inside <style> tag (instead of linking to it with <link> tag) definitely is one way to do this, but not what I meant. That way user would have to download those styles again for each page they view instead of letting the browser cache the stylesheet file on first load. What Soma was explaining above is pretty much exactly what I meant with option 1: put your style.php into root or a folder in it, at the same level with /site/ and /wire/ directories. Let's imagine that your site lived in /example.com/ directory: /example.com style.php /site /wire This way you can link it to any other template with <link> tag. With option 2. above I meant a structure like this: /example.com style.php => only things you'd put in this file would be CSS header and "include(./site/templates/style.php);" /wire /site /templates style.php This second method is no "better" than first method, mostly just more complicated. It'd let you put your style.php inside templates folder, though, if that's what you want; I myself prefer to keep all template-specific content there, so I always know where to find them when making changes. This method isn't pretty but it does allow for style.php to live inside templates directory and still get referenced with direct URL. By the way, if I may ask, what kind of stuff are you using PHP for in your stylesheet? I'm just trying to wrap my head around exactly why you'd wish to use PHP in your stylesheet but not have it as a PW page -- wouldn't it be nice to be able to, for an example, manage possible variables directly from PW?

Love the design - especially the dark tones and that teaser thingy on front page. Really makes the site stand out. On the other hand, some of the typography, text block widths, margins between sections etc. after that seem like they still could use some extra care. Also some of the sections with content (News, Downloads) seem very, very raw.. but I'm sure you're aware of all of these already Not sure if you've thought about this, but your portfolio acts kinda strange when individual items are visited with direct URL or from sitemap; just take a look at http://www.herxheim-ecommerce.de/portfolio/test-your-usability/. No navigation, no nothing. It's probably because they're usually shown within a modal window, but this still seems a bit awkward.

I'm afraid that I'm still a bit confused about your situation and thus my answer might not be completely valid. I don't see any problems in including a .php file with include() even if it's not related to any template -- I'm actually doing that a lot when building sites with PW. You can't access a .php file inside /site/ or /sire/ with direct URL (and thus you cannot use them directly from <link> tags etc.) but include() within a page (/ template) is completely different thing. Anyway, there are three other options I can think of right now: 1. Put your style.php in the root of your website, outside /site/ folder. This way PW (or actually mod_rewrite) shouldn't have a problem with it. 2. Same as option 1. but with a twist: add style.php to site root and from there run include('./site/style-directory/style.php'). Only thing this would achieve would be that your style.php would actually live in your styles folder. Not exactly pretty, but it should work. 3. Add new rewrite rule to your .htaccess to allow direct access to file / files in your styles folder. This option also sounds like a hack and I wouldn't really suggest doing it, though. I'd go with having style as a normal PW page; example.com/style/ or something like that. It's pretty much the prettiest option I can think of right now and would make adding new user-definable CSS settings a breeze.

Have you tried using URL instead of ID: http://processwire.c...t=/api/concept/ and so on? Although, judging from the symptoms, I'd be rather surprised if the problem wasn't mod_rewrite-related Edit: I'd recommend doing a Google search (I'm not a big fan of our dear forums built-in search thingy..) with something like "site:processwire.com/talk/ mod_rewrite". You'll find quite a few tips & tricks for troubleshooting + fixing mod_rewrite-problems that way.

Lars: I'm not completely sure that I understand your question, but the way you've done it (php-file with css-header) is, as far as I know, pretty much the cleanest way to do this. Is there a reason not to use that method? I'm sure you've tried Googling this already, but this solution does seem rather common: http://css-tricks.co...ables-with-php/, http://stackoverflow...-file-extension, http://net.tutsplus....under-the-hood/ and so on. I'd recommend you stick with it. It's pretty enough.

As a clarification to my original post: I've no doubt that this system is very powerful and lets you do a lot from that one single view. I also have no problem with a dashboard style UI, since it does have it's merits (though quite often dashboards are added just because they look cool.. and no, that's not a very good reason.) What I don't (and won't) understand is this particular choice of UI style. In that example above I see a huge pile of icons, all visible at once. Not only does it look stuffed, some of those icons really fail to convey what action they're tied to.. and I'm also pretty sure that someone as clumsy as me would way too often click wrong one without realizing that and cause unnecessary problems. There's a reason why many UI designers like to hide action buttons by default. PW has taken a completely different approach, yet it still manages to solve similar problems: * only the most common (and only nondestructive, unless you've installed a module that adds destructive ones among them) actions are available via tree, * actions are hidden by default and only visible after a page name has been clicked, thus reducing the clutter of tree view, * text is used instead of icons (the actions of which you'd have to either guess or remember.) It's simple and powerful and has a very small chance of confusing users. Of course once you've used a system for long enough you'll know exactly what all those tricky little buttons do -- but with the approach PW has taken none of these problems even exist in the first place. My point is that a powerful system can still have well designed UI. Or is that too much to ask? Regarding the point @adamkiss made about root != pages approach, I guess that makes sense in some (limited) situations. Still, PW has proven that even many of those situations can still be handled very well with it's "everything lives within one tree structure" solution. So forgive me for being somewhat skeptical here. If there's a need to create another tree, I'd rather see it as a completely separate entity, not artificially stuffed within one huge pile of everything. But hey, that's just my opinion -- everyone has one (or more) of those

First time I looked I only saw the left side of that thing and thought that "well, this isn't so bad." Now I wish I didn't see the rest of it. @MarcC: that (root != home) is a strange thing, really. Never understood it myself. I guess there must be something that we're just missing though -- I've had more than one client specifically request that kind of structure before..

@netcarver: luckily there's this neat new thing called "the Internet": http://www.noupe.com/how-tos/10-ways-to-automatically-manually-backup-mysql-database.html. Periodic MySQL dump is easy to set up and enough for most cases

Should probably be ashamed to admit it, but I wasn't fully aware of how much you can do with built-in filter / sanitize functions and their various options. Lets just say that I could've avoided a lot of RegExp-related headache by checking these out more thoroughly. Many other interesting things mentioned there also -- especially in the testing and caching parts, I bet those will come in handy as reference material. Overall very nice article, so thanks for sharing this SiNNuT!

That pretty much sums up how it works with most (if not all) GitHub projects and ProcessWire is no different in this aspect. It's a good idea (even necessity for a large project like PW) to have dev branch for new and possibly unstable features.. although, as we all know, when it comes to producing code of superb quality Ryan is a true ninja

Regarding Process Export Profile diogo mentioned above, does anyone have experience about how well it works with large sites? I myself have seen that it works well with your typical site installation, but what if there are (at least) multiple gigabytes of data (assets) etc?

Just out of interest, Ryan: I'm guessing that these logos are free to use for pretty much anything we can think of (without limitations), is that right? Most likely I'm being too conservative here, but some kind of license info would be nice addition (As a sidenote, I'm actually thinking about ordering some ProcessWire t-shirts..)

Sorry, can't really answer your first question, haven't seen a setup that huge so far. So far large sites have worked pretty nicely (talking about <100,000 pages here) with the exception of repeaters causing trouble here and there. I've heard that there are some really nice speed improvements coming regarding those, though -- but I'd still generally encourage you to avoid them when building this kind of site (unless someone can prove me wrong on this one.. ) Anyway, first of all I'd suggest you to take a good look at ways to maximize site speed without applying any complicated tricks -- cutting HTTP queries to minimum, compressing CSS, JS and images, using cache as effectively as possible etc. Also: if you need to host your music videos yourself (though hosting at YouTube or similar service would generally be a much better solution) I'd create an external server just for static content like that; "videos.example.com" or something like that. All the big guys are doing stuff like this already. Regarding splitting PW site on two (or more) servers, that should be possible in theory, but would require a lot of work and could be a little "hacky." The main problem here would probably be assets; you could have multiple servers running PW while still sharing one database server (and a load balancer in front of those servers) but you'd need to find a way to keep assets synchronized. I don't really have a viable solution for that at the moment, though it's something I've been looking into too -- currently handling stuff like that with rsync, but that's nowhere close to "real-time." I think someone somewhere (?) mentioned that PW sessions can also be saved in database, which would help a bit here - don't know if that feature is still in dev branch though. Another solution would be to run a main site on one server + separate "subsites" on others (example.com, genre.example.com, anothergenre.example.com, users.example.com, auth.example.com, comments.example.com etc.) but that'd make communication, searches etc. between those sites way more complicated and at least require some kind of SSO solution. To be honest quite often it just makes sense to keep things running on one server (with the possibility of separate servers for database + static files as mentioned above) and when requests pile up just put some extra muscle on those servers. That's another reason to love virtualization.. keeps things nice and flexible Edit: the more I think about this, the more I start thinking that the viability of having one PW site run on multiple servers simultaneously is related to how often assets are added / changed / removed. If your typical user doesn't have the right to manage assets, it would be relatively simple to implement a server-side watcher that would sync assets between sites / servers. Rsync (for an example) has an option to only sync files that have been added / changed, thus you wouldn't have the need to sync all the files between servers whenever something is changed. In this setup cache files could cause some trouble, though -- not sure how to handle those properly. A filesystem watcher could be a self-made server-side combination of rsync + cron (non-realtime) or some of the already available applications, such as Lsyncd. Quite possibly you could also have the watcher work as a PW module, hooking into file save operation and then invoking rsync / other sync method via exec() -- not sure if there's an easy place to hook into yet though, just throwing in some random ideas here. Oh, and all of these ideas rely heavily on you having complete control over your servers. I hope that's the case. They're also based on my relatively low knowledge of PW + server administration, so there might be a much better solution available..

So, basically you want to render a form with exactly the markup that Twitter Bootstrap requires, right? If that's the case, then I would imagine your only chance (right now) being looping through fields and generating markup on the fly yourself. There's no shortcut for this one, I'm afraid. Depending on your form and how static it is, this might be an easy task or a very difficult one. If you're only having to deal with text inputs and textareas, it shouldn't require too much work - but supporting all possible fields (especially images, files etc.) would be a real pain. Try to keep things as simple as possible