teppo

Horst is right, as far as I can tell, but I'd also like to point out that stacked ternary expressions are a PITA. PHP manual itself suggests avoiding them, and so would I -- not only does your first example work, it also looks better and is much easier to read than the latter one. Getting everything on one line is hardly a goal worth striving for For more details I'd suggest taking a look at http://php.net/language.operators.comparison#language.operators.comparison.ternary and specifically the part about stacked expressions, "non-obvious ternary behaviour".

Sorry, just trying to get an idea of what's going on here. So far it sounds like your domains are configured correctly, or at least they work (mostly) as expected. The fact that hortonsshortuns.com is identical in content to www.hortonsshortuns.com and both versions work is a problem (for this module and from SEO point of view) but as long as you use the version that you've configured this module to use, it's not really the issue right now. Anyway, this makes me think that there could be something wrong with the Multisite module config or the page it's trying to point the user to. If you're using Soma's variation of Multisite, I don't really know anything about that (never used it), but: It might be helpful if you could post here literally how you've configured the module (every config setting and value exactly as they are on your site, either as text or screenshots)? Also, just to rule out any inconsistencies, please double-check (or triple-check, or whatever) that the related page branch is correctly named (name field, not title) and placed in the page tree below the root page, something like this: - Home - whatever - whatever - hortonsshortuns.com - whatever - whatever - ... and so on Looks like this has been way more difficult than it should've been, but hopefully we'll get this sorted

1) There are no plans to drop support for it, if that's what you're asking -- so yes, it can be considered a longterm solution. On the other hand, you might consider that with ProcessWire you don't really have to upgrade your site every time a new release comes out, so in that sense it wouldn't even matter that much if specific core feature was, at some future point, superseded by something different. ProcessWire isn't like some other systems, where just about every upgrade is essentially a security fix -- so far there have been no vulnerabilities in the core code, and we intend to keep things like that. There's also one potential gotcha here: what you're describing above kind of sounds like you'd benefit more from the Multisite module instead of the core multisite support. With core multisite support all your sites share common core code, but have their own templates, site-specific modules and databases. Essentially they're separate sites with some shared codebase. That's important when/if you, for an example, need to re-use data from one site to another. With Multisite module there's one base site, and all other sites live in the same page tree but can be accessed with their own domains. By default they share same templates, modules, etc. in addition to the core code, and can also use content from each other (or the base site) easily. Note: multisite module sharing same templates doesn't mean that you can't customise templates per site. The workflow is just a bit different. It's also important to consider when it comes to managing said sites. Multisite module makes it easy to manage all sites from one place (i.e. the "subsites" are just branches in the main sites page tree), while with the core multisite support they're separate sites, with their own user accounts, admin views, etc. If your sites are going to be managed by different people anyway, this probably isn't much of a benefit, so it does really depend on your use case 2) If you're referring to the commercial modules mentioned above, that depends on how you use them in your setup, and there might be some limitations. You might want to check this out first by contacting the module author (Ryan) directly. I'm not entirely certain on the details at the moment, and wouldn't want to spread any misinformation here 3) Yes and no -- not exactly identical, but we've built a few multisite setups. The biggest issue has usually been the management part, i.e. how it should be handled in the first place, what happens when later on the client decides that each site does indeed require specific permissions, etc. Most of that is now much easier than it was just a few years ago. Permission management, for an example; modules like UserGroups and Dynamic Roles have made a huge impact in this area. Hope this helps a bit!

For the record, "Introduced in" seems a bit off in some cases. http://cheatsheet.processwire.com/page/built-in-methods-reference/page-parentsuntil-selector/ for an example; this was apparently introduced in 2.3, not in 2.0. I just stumbled on this myself, while working on a 2.2 site..

Thanks, I'll take a closer look at the ones I've got access to, probably later today. It should be noted that you've also been installing some modules that have not been declared as compatible with 2.5, which is why your comment about "removing from the directory" seems a bit off. Either way it's a good thing if we can catch (and preferably update) such modules. Another note would be that while ModulesManager is a great module in itself, it would be nice to rule it out as a cause to the issues, i.e. installing problematic modules with native tools and seeing if that causes the same issue These are never intended to be installed simultaneously; VersionControlForTextFields is for PW 2.4.0 or earlier, there's no reason to use it for anything later than that. Also, PageSnapshots.module is not identical between these modules, so removing one of them would only render one of the modules unusable -- not a valid solution. Admittedly that's a bit of a weird situation you've got there, but also one that mostly happens if you start blindly installing everything you can get your hands on, and is easily fixed by removing one of the modules. I'll see if I can easily add some way of preventing that without unnecessarily complicating the modules themselves. It might make sense to add a new "incompatible" list to module config; this way module authors could specify modules known to be incompatible with theirs. Not sure if this really is common enough to justify such a thing though

You might want to take a look at Admin Hot Keys. It's a module that does essentially what you're describing here.

It's an issue of the modules directory: https://github.com/ryancramerdesign/ProcessWire/issues/793.

I'm not aware of any 100% safe way to break module backwards compatibility without risking some older sites having issues. Tagging and adding a note about it here and at the modules directory is an option, of course, and another option would be creating a new branch for 2.3+ and leaving master as-is. Options, options.. Support for specifying where to find a version of a module suitable to specific ProcessWire version could be nice addition to the modules directory and/or native modules manager, but that won't help us much here. Sounds like a wishlist item to me

Antti: that'd be great, but would that mean dropping compatibility with < 2.3.1? Or is conditional autoload backwards compatible? Should we care about that? As a sidenote, perhaps, this would also make Inputfield::render hook useless (it's mostly useful when template is admin), though I'm not entirely sure at what point Admin started handling the 'modal' GET param properly either. Perhaps it's no longer an issue in 2.3.1. .. oh, and didn't mean to rush you, by the way! Just wasn't sure about the best way to point this out

Which ProcessWire version are you running? Not much of an answer yet, sorry for that, but there have been various repeater-related fixes, so this may help to rule out some specific issues.

Antti, I'm not sure which one you read more often, so posting here too: could you take a look at issue #11? This is a potential fix for "modal admin issues", but I'd love to hear your views on it.. does it make sense, etc.

Sheesh, you're putting an awful lot of pressure on me!