teppo

@apeisa, thanks for this module -- it's working beautifully! For our needs I had to implement support for alternative domains (each extra domain can have n alternatives, which all point to the same location.) With separate domains for development and secure addresses -- not to mention that in this case the client required alternative domains that couldn't be handled very well with just redirects -- that was pretty much the easiest way to put together a consistent experience. So, basically I'm asking if you'd be interested in incorporating that addition in the main module if I sent you a pull request for it (of course once I've tested it properly first?)

@apeisa: thanks, that's actually a good idea and something I could probably work with. I'd still prefer to have rootParent work consistently with or without Multisite in use -- it's a core feature after all and I'm kind of used to it already

Pete, you're right in saying that download size won't make a big difference, but complicated codebase sure does. Of course good code should be modular and allow relatively minor additions (such as new auth methods in this case) without the need to alter "core module"..

Little bit of background: I'm trying to use (and hack) Multisite-module by @apeisa for a client project, but got stuck on one somewhat annoying problem: it doesn't do anything to $page->rootParent(), thus that still returns site root or first page after that, which isn't very useful here. Most straightforward way to override this would seem to be hooking into rootParent and altering it's return value or completely replacing it with my own method. I've tested this with local installation and this method seems to work. So, my question is: would it be possible to make $page->rootParent() hookable or do I have to hack my way around this problem? Not really sure if altering rootParent is a common need, but it sounds justified in cases where you're overwriting PW URL scheme somehow (like Antti's Multisite module does.) Of course if there's a better way, I'm open for ideas too

I thought it might be that too, but on the other hand PW doesn't seem to have any problem with me creating a setup where one page with view access denied for guests has another page below it with view access granted to guests -- in that setup guests can still access that subpage, even though they cannot access it's parent. Or perhaps it's completely another matter when we're talking about the root page..? Anyway, to sum it up, I'm a bit confused about what's happening here

I've solved this problem in the past with similar solution SiNNuT mentioned; in our case all templates actually use one template file which functions as a front controller and redirects queries to actual template files, making it relatively simple to determine whether or not access should be (artificially) limited. Would still like to hear an answer to the first question by Ryan / someone who knows exactly why this is happening. It's more than a bit annoying sometimes and this kind of solution still feels a bit like a hack

That's right, it's only displayed in modal window with ajax query

@diogo: then again, stuff like that should probably be accessible by search engines etc. I'd rather find a way to distinguish between modal queries and direct ones and when page is accessed directly redirect user with Javascript (to still allow bots normal access) to the page it's supposed to be accessed from and open correct modal window based on window.location.hash (or similar method.) Done this before, not nearly as complicated as it sounds

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..