teppo

@WillyC is right; the problem is most likely that you're calling renderDirectorProfile() .. a) for user that doesn't exist or b) for user that exists but doesn't have any images available. Adding proper checks for $user->id and count($user->images) / $user->images->count() before trying to output content is strongly recommended: function renderDirectorProfile($person) { if ($person) { $director = wire('users')->get("name=$person"); } if ($person && $director->id) { $o = "\n<div class='member span4'>"; if (count($director->images)) { $directorsImage = $director->images->first(); $o .= "\n\t<img src='{$directorsImage->size(369, 369)->url}' alt='$director->fullname' />"; } $o .= "\n\t<h2>$director->fullname</h2>" . "\n\t<span='position'>$director->position</span>" . "\n\t$director->body" . "\n</div>"; } else { $o = "<p>Couldn't find director.</p>"; } return $o; }

You can definitely use size() in functions. If you take a closer look at the error you're getting, it's not saying that you can't use size(), but that you can't use size() "on a non-object", meaning in essence that $image (or whatever you're calling the size() method on) isn't defined or isn't valid object (it should be an instance of PageImage in your case). Without seeing your code this is just a guess, but it would seem that this is a scope issue, i.e. you're fetching the $image outside function and then trying to use it inside or something like that. Since $users->get() shouldn't work within function context at all (you should use wire('users')->get.. there) I'm wondering what exactly you mean by "equivalent" solution here

I'm not entirely sure that I get your whole setup, but just a small pointer: The error you're seeing most likely comes from FieldtypePage and means that Page with ID "ID#" (from your error message) is not a valid value for "Field-Name". First thing I'd do here is check the settings of this field ("Field-Name") to see why this page isn't valid for it. Hope this helps a bit.

@etling: that's right, include the domains you'll want to use this site with there and things should work just fine. @bwakad: sorry, I'm not really sure what you're saying there, but whatever domains your site uses need to be included in httpHosts config setting. It's that simple.

You'll want to make sure that your Apache user has read, write and execute permissions to assets and it's subfolders. Other directories you rarely need to worry about. Setting permission 777 to whole assets directory recursively (chmod -R 777 site/assets/) is more than enough. You could be more specific and only allow it to only write into assets/files/, assets/cache/, assets/logs/ and assets/sessions/, but then there are modules that write directly to assets folder and would fail after this. Bad Gateway 502 as a result of this sounds like some strange server setting -- I've seen shared hosts throw errors if a file is executable/writable by all users (security feature attempting to mitigate risks usually caused by shared hosting itself, kind of ridiculous really), so this could possibly be something like that. In those cases you'll need to configure permissions properly: only give write and execute permissions to the user Apache is running as (often that would be your own user account). The host most likely explains this stuff somewhere. Apart from that I've no idea what could be causing that.

I'm guessing that you're already familiar with it, but the Multisite module Antti wrote does awesome job when you want tightly connected sites. If that's too much, custom interfaces (or pages web service, as you already mentioned) make it possible to design exactly the type of coupling you need. Just saying; your idea sounds great, though not sure if this would make that much sense as a core addition, considering that it's pretty specific need you have there and all the building blocks are already available, so to speak

You should be able to do this with sanitizeValue(). My experience with fieldtypes is very scarce, but AFAIK that's what this method is for Edit: unless you're already using it as a base for your own fileldtype, take a look at how sanitizeValue() of FieldtypeEvents works. That pretty much explains it, I think. If you don't like the value, throw exception. I'm not entirely sure if it's possible to entirely disable setting value via API though, if that's what you're after -- i.e. giving $page->yourfield a value that's an instance of the object it expects -- without disabling page edits etc. too.

Actually what DaveP suggested would make a lot of sense as an addition to default ProcessWire .htaccess. Commented out by default, like it is in HTML5 Boilerplate, probably. I did not know that proxies dislike query strings, but that does make sense -- and I'm unlikely to be the only one caught out by this.. Taking things a bit further, options for enabling / disabling / configuring certain .htaccess settings easily during install phase could result in some very interesting possibilities. That's probably way out of scope for this particular discussion, though

It would be awesome if we could simply notify authors and they would update their content, but I'm also a bit skeptical if that would work, how many would react in given timeframe.. and how many modules we might end up losing in the process. Don't know if that's really worth the risk. For the paranoid types (like me) seeing what license a module is under is very important, especially if I'm planning to use it in work projects and not just for fun, but in all honesty most authors probably won't be going after users of their modules with legal claims anyway I don't really know what would be the best solution here and Ryan would probably be the right person to make that decision. In any case adding a way to define this info in the modules directory and sending an email like you mentioned would definitely be a good start. Using a license usually means including license text somewhere and/or mentioning in your source code what license it's under. GNU licenses (GPL, LGPL) are only ones I know to especially state that you should include full license text in every source code file you've got under that license. That's a bit over-the-top, to say the least, and most authors simply skip that part. For my own projects I've included LICENSE file within the repository and added PHPDoc @license tag (linking to text format license) to all PHP files -- that should at least make my intentions clear.

From legal perspective you can't really assume that, especially since we have already established that ProcessWire modules aren't automatically under same license as ProcessWire itself. There was a rather lengthy discussion about this here. Can't have it both ways, I'm afraid. Code that doesn't specify a license is simply protected by copyright law, meaning in essence that you can't use it legally without the authors consent. I'm no expert in (especially international) copyright law, so please don't take my word for it, though. Luckily more trustworthy sources, such as GitHub, have written tons of good articles about this

Small(ish) request related to modules directory: could we get a field for selecting license used by the module? At the moment it's often very unclear what's the licensing policy for an individual module. I'm hoping that this would -- in addition to making this information more obvious when browsing modules -- also give module authors a slight (and much needed, I'm afraid) nudge towards actually defining which license the module is distributed under. A simple text field would be enough for the time being, but a list of possible / most common licenses like GitHub has implemented would, of course, be even better.

Pages are the preferred way to do this and 30 pages is absolutely not a problem. You'll run into usability issues with select field itself much sooner than any kind of problem related to number of pages behind the scenes..

@pwired: that's one way to view it. From my point of view typography is an essential part of the design process and should be consistent across whole site, not something you (or the client) decides on a whim -- absolutely no offence intended, but from my experience that's what too much control eventually leads to. As a part of larger set of design decisions typography contributes towards the message that a particular site is designed to send to it's end-users. Classic example would be a "humorous" font used on otherwise very corporate-looking design. That's not just a sign of bad taste, it also sends a mixed message about the site and -- even more importantly -- the entity it represents, i.e. your client. Not only that, typography is also very important factor from usability point of view: Having the ability to change these things on the fly may feel good in that particular situation, but it contributes towards making the site messy and the experience end-users will have using it inconsistent and unpredictable, raising the bar of using the site among other issues. The client may or may not be expert when it comes to readability and other factors directly affected by typographic decisions. I'm personally not that interested whether a font looks good, but I am interested in whether it's readable. I do realise that this is something you can't always control. I just think that it's important to know what's being sacrificed when you're making choices like this. This is just one example of the kind of things you will sometimes have to explain to the client. If they still decide that this is important, then by all means go for it

I'm not particularly interested or knowledgeable in image optimisation myself (as long as I can still tell what's in the image and it doesn't consume too much disk space and/or cause unnecessary slowdowns all is good) but this sounds awesome! GD vs. Imagick is clearly something that's been bugging some folks and we'll likely be seeing even more topics about that in the future. I sincerely hope that you guys find the time to take this further

OT: for some reason a slight modification of this has stuck to my head; "expert is usually right, but the client always has the last word". As experts of our business it's our obligation to inform the client if something they're requesting doesn't make sense or if there's a better way to do it, but in the end it's the client who pays our bills and decides whether to trust our expertise

I've been reading about Hack this morning and I must admit that I'm getting quite excited, to say the least. Just wanted to share this with you folks, in case that someone else might find this interesting too. Long story short: Hack is a new language based on PHP, used and developed by Facebook. It's compatible with existing PHP code apart from certain features, such as variable variables, that they had to remove to keep things consistent. There's a bunch of new features that Hack introduces (such as asynchronous functions, lambda expressions and collections, just to name a few), but it's primary addition is (optional) static typing and real-time type checking via local server sniffing file changes -- something that should come in handy especially when working with larger and more complex codebases. For the record, I don't particularly have issues with PHP as it is, but it seems to me that Hack introduces exactly the kind of features that I've been missing without sacrificing anything I couldn't live without.. not to mention that this is another good reason to finally try HHVM, which is now able run both Hack and PHP