Pete

I think I'm going to use the two template approach on one site just because it's a reasonably complicated layout and is quite image-heavy when you get into the articles. That way I can serve up a mobile-optimised layout with much smaller images. Just got to finish the normal site first

And here's my function for the single drop-down module config field if it's useful to anyone. private static function _createInputfieldSelect($ipName, $ipTitle, $ipValue='', $ipDesc=''){ $field = wire('modules')->get('InputfieldSelect'); $field->name = $ipName; $field->label = $ipTitle; $children = wire('fields')->find('id>1'); foreach($children as $child) { $field->addOption($child->id, $child->name); if (!empty($ipValue)) { if ($child->id == $ipValue[0]) { $field->attr('selected', 'selected'); } } } $field->required = false; $field->description = $ipDesc; return $field; }

Oh yeah I think I've just been going ASMSelect crazy recently because it looks so nice and overlooked the obvious solution I think in my case since the site I'm working on has about 30 fields so far it might be better for me to use autocomplete, but I've not got so many that a normal select wouldn't be the easiest and best option. Plus people will think I've gone crazy if I make it an autocomplete field and most sites don't have that many fields (an autocomplete for a dozen fields would be silly for example). Thanks for all of the suggestions though Soma - very useful indeed!

Hi guys I'm tweaking a module of mine (SocialTwitterFeed) to do something else and need to have an ASMSelect in the config screen -this bit is simple enough, however how do I limit it so the user can only select ONE page? Here's the current code: private static function _createInputfieldASMSelect($aName, $aTitle, $aValue, $aDesc='', $aPath='/') { if(!isset($aValue) || !is_array($aValue)) $aValue = array(); $modules = Wire::getFuel('modules'); $field = $modules->get("InputfieldAsmSelect"); $field->attr('name', $aName); $children = wire('pages')->get($aPath)->children; foreach($children as $child) { $field->addOption($child->id, $child->title); } $field->attr('value', $aValue); $field->label = $aTitle; $field->description = $aDesc; return $field; } In this case, it's being used to select a field, so here's the more relevant code that works, but currently selects multiple fields instead of just one: private static function _createInputfieldASMFieldSelect($aName, $aTitle, $aValue, $aDesc='', $aPath='/') { if(!isset($aValue) || !is_array($aValue)) $aValue = array(); $modules = Wire::getFuel('modules'); $field = $modules->get("InputfieldAsmSelect"); $field->attr('name', $aName); $children = wire('fields')->find('id>1'); foreach($children as $child) { $field->addOption($child->id, $child->name); } $field->attr('value', $aValue); $field->label = $aTitle; $field->description = $aDesc; return $field; } I posted both as thought the latter might be useful to someone already familiar with the former, and I'd be interested to see if there are any major differences required for the two. Cheers! Oh, and the addition is going to be that you can specify a field for the module so that you can enter a customised message for a given news item/article/whatever to accompany the title and link in the twitter post on a per-page basis rather than the blanket default message in the current version - though it'll fall back to the default message if no custom message is selected. Getting complicated, but very configurable

Yep - I didn't think it would be an issue really memory-wise, but as I just installed an 8kb (huge ) module and looked down the list at a few others that run on page load an/or save, I just thought they might begin to stack up eventually. I suppose the only issue with those is if they're designed to use selectors and have a lot of data to look through and are being loaded unnecessarily, but then that's probably more to do with the module's design, as if it's built well enough then one of the first checks on one of the first lines of code should be whether you're in the admin or not (if that's a check you need to run in a specific module). I guess I worry with my own modules more than others

Not sure context is the right word for this, but I'll use it anyway! It just occurred to me that the more modules you have the more modules the system has to run to see if they apply to the current action. Some run solely on the front-end, some only in admin, and many only when editing pages. Would it not make sense to have some basic information required for ALL modules and stored in the database so that the system doesn't have to include and run every module to see if it's applicable? I know there's scope to go crazy with it, but I think that a few basic settings would save a little overhead. I also know that a few kilobytes never hurt anyone so what's all the fuss about That's assuming that this is how it works and I'm not missing something obvious.

Amusing mis-spelling there - wonder if it was intentional or iPhone

That last link wasn't very useful either after reading it again as several posts lile that one assume that because octet stream tells the browser to expect application data that it will be a .exe file, which is not the case - its any binary file. This link better describes it: http://mimeapplication.org/octet-stream.html It's more of a catch-all that prevents us from having to specify a correct MIME type. Thinking back to the download script I used to use again, there was a list of MIME types in the source code and if a file didn't match any but was still an allowed file type (as set by the user - same as you can do in ProcessWire) then it defaulted to this. Not sure if that's much help. MIME types are just yet another thing where if you're not careful you end up with different results in different environments, but come with a handy catch-all that seems to work in all the cases I've used it in.

Pure fluke. I figured that there must be something wrong with the headers coming back from the server since it worked on other servers, and found a blog post where someone said it was good practice to give the browser an idea of the content type (but alas I didn't bookmark it... think it was a search for "xhr header" so if I find it I'll post the link. From my days working with an old download script, octet-stream was the default mime-type - think of it as a slightly lazy catch-all. You could specify the precise file type, but you would then need to have a mime-type table to send the right header for every possible filetype allowed by a field (which is nearly impossible as the user can specify their own types!), whereas in my experience octet-stream was fine for all cases I've run into in the past with those sort of scripts. In fact, since this was a Firefox issue, this post seems rather more helpful than the one I originally found as there's a section where it attempts to work out the mime type: EDIT: https://developer.mo..._XMLHttpRequest EDIT2: Although Mozilla's example above defaults back to plain text, so not the best example as what we're sending is a file. There's a brief description of octet stream here: http://kb.iu.edu/data/agtj.html

Fixed this. Bizarrely In InputfieldFile.js I added the following: xhr.setRequestHeader("Content-Type", "application/octet-stream"); after this areound line 203: xhr.setRequestHeader("X-FIELDNAME", fieldName); It seemed to then basically stop producing a 404 error and stop malforming the JSON. I suspect it is a server/PHP combo that caused it as the server with the issue was PHP 5.2.7 whilst my dev server is 5.3.x, but could have been any number of variables. Since the fix in pretty harmless I guess it may as well be added to the core? I'd do that Git thingy but Git is being a git and not working for me at present Also, whilst I was there, shouldn't this line: xhr.setRequestHeader("X-FILENAME", file.name); have an extra hyphen, so file-name instead of filename? I've seen it with a hyphen elsewhere so not sure if that is correct (presumably either can be used else it wouldn't work would it?). Still cannot get the progress bar uploader working in the latest version of Opera, but since I don't use Opera I've got less incentive to try and fix that one

Antti - this doesn't work on my live or dev serer in Opera 11.6 - what I mean is that the progress bars don't show and no thumbnails appear. Strangely, clicking Save shws the uploaded files on the next page, but that's a little inconsistent. Just to throw another issue into the mix, on ONE server I use, images never finish uploading in Firefox, but finish fine in Chrome. I've been working with ryan on another issueand he's fixed one error message I was seeing in the source code, but on this one server I get the json error mentioned in this thread: - also worth checking out the screenshot from Firebug I attached as the ajax request is oddly throwing a 404 error for a page we know to exist (is. the one I'm editing!) but as I say this is only in the latest version of Firefox. Strangely FF can upload fin on my local server as well as other servers so I suspect that that one is an environment issue whereas the Opera issue is present on any install. I'm not sure if the FF issue is related to the Opera issue though, but thought it was worth mentioning as they're both related to the image uploader.

Back when I played with it a few years ago, you could set the crop box to be the actual crop size (so if you uploaded a 1600x1280 image and your image is to be cropped to 320x200, it can give you a starting box that size that you can't make any smaller, but could make bigger proportionally - that's what I was talking about (although I suspect you already worked that out ). If accidentally uploading images that are smaller than the crop the crop box could just scale down so it uses up as much of the image as possible or something. Just an idea - it all works fine as it is and I'm looking forward to playing with the per-field settings later today/tomorrow Just out of interest, to the per-field settings work in the new per-template settings that ryan introduced recently for things like naming the same field differently for different templates? Being able to have just one "images" field and set the settings for that field in the many templates I use it in would be awesome

I do like the idea of Min and max size as it is currently possible to create a small crop that is actually enlarged on the site. I'll have a think about config later and see if I can come up with a suggestion.

It's a good read My thought though would be to make it personal if these end up on the new PW site - write them as customer succes stories rather than 3rd person case studies (which would just mean re-wording it to the 1st person in this case). What do you guys think?

I did that - it started spitting out data in a seemingly endless loop - looked like the current page data over and over again.

The source of the error appearing at the beginning of my code was a PageAutocomplete field with a custom selector - template=template1|template2 that was set to: "Single page (Page) or empty page (NullPage) when none selected". Presumably this shouldn't return an error though when viewing the page edit screen? The message goes away now when I change it to "Single page (Page) or boolean false when none selected", but I'd prefer it to be a NullPage that's returned as my code is already set up to use that. That's one thing solved, but it still won't let me upload images on the live server (which I suspected would be the case since it does locally ).

I like this module as it reminds me of WayFinder for MODx - definitely one of the most useful tools I used to use for getting a site up and running quickly.

Mine seems identical: foreach($this->value as $page_id) { $page = $this->pages->get((int) $page_id); if(!$page || !$page->id) continue; $out .= $this->renderListItem($page->get($this->labelFieldName), $page->id); } It turns out that that same text does appear in the source on my local server, but I can successfully upload images on my local server (same code - synchronised all the files today). I guess that they're two unrelated issues in that case? Oh, just spotted this weirdness in Firebug (the two errors are obviously it trying to upload the image). Not sure why that URL would throw a 404 as that's obviously the page I'm viewing - unless of course it is prepending my error message above to any JSON output?

That would be nIce, I agree, but not too simple the way the module currently works. Now that PW has per-field settings for the same field on different templates I can see how something like that could work - I just have no idea how to code it

I've got the same issue on one of my servers What I have noticed, and I can't pin this down, is that I have the following error before any other page output in the admin when I'm editing a page and viewing the page source: <br /> <b>Notice</b>: Trying to get property of non-object in <b>/home/mysite/public_html/dev/wire/modules/Inputfield/InputfieldPageAutocomplete/InputfieldPageAutocomplete.module</b> on line <b>78</b><br /> I only mention it as I've not been able to track down what that is (uninstalled all but the base modules) and I wonder if this output is interfering somehow? It's worth noting that the site is an exact replica of my local copy and image uploads work there so it's more likely the environment. I'll grab a phpinfo() output and PM you ryan.

Welcome fellow MODx user As someone who's migrated a few sites to PW from MODx already, and is in the process of converting a site with dozens of template variables/snippets and hundreds of pages from MODx to PW, I'll echo what's been said above to some degree: You won't need PHP in the back-end. It's a bold claim as I don't know what TVs you had set up, but if you would like to post a few examples I'll be happy to show you how to do them in PW. The hardest part is unlearning whichever CMS' you've used previously - I still find myself looking for more complex solutions when there are perfectly easy ways to do things in PW. Overall, ditching my snippets in favour of creating more readable code inside templates (with good old-fashioned includes) and not having to use TVs, my code has been reduced dramatically in terms of length and is easier to read. So... not sure where I was going with this - but yeah, if you'd like to give an example or two of how you use TVs now then we can show you the PW way.

I won't be first, as the one I'm working on has been in production for well over 3 months now, but I reckon I can post the first one about a gaming magazine style site

I love it when that happens - happened to me with something the other day (although it was half an hour to do something I thought would take half a day - same principle). It certainly starts to make up for those frustrating times when running into coding roadblocks - those tedious ones where the answer turns out to be easy, but only after lots of time and swearing - I much prefer it when it happens this way around

Thinking about it, I'm not sure why I didn't just do that instead. Oh well

I think that these links would be incredibly useful in the admin interface when adding pages. It is annoying when you just want to add a dozen pages to one section and you have to keep going back to the page list, especially when your structure is a few levels deep and it takes a while to animate. I'm not complaining about the animation though - that's perfectly highlights where you are in the tree, but it does break the workflow a bit when adding lots of pages.