ryan

I'm not sure initially. Do you see any javascript errors or anything like that in your browser developer console? Fieldtypes like the Repeater and Autocomplete weren't ever really intended to be used outside of ProcessPageEdit, so it's possible there's some dependency in there that I'm not thinking of. It seems like the most likely possibility is a missing JS file or something which may turn up in the JS console, but hard to tell for sure.

Not sure. I think it's either a children's game or has something to do with MS Office, or both.

Not really sure how to tell short of trying it myself, as I'm not aware of any issues with uploading, and I use a Mac all day long. It might be helpful to get a better look at those "out of memory" and "imagesizer" errors. Also, if you can take a closer look at the images and see what DPI and color space they are using? For instance, I've occasionally seen some strange things with PHP's GD functions when going into 300 dpi or CMYK images. If you want to send over the images and/or login info, I'll be happy to give it a go on my mac to see what happens.

Sounds good, I had planned on adding a quality setting with the $options array to the size() function like mentioned above. I'll push this forward in 2.3. Interrobang I think that looks like a good clean route too--decorating an image with an imagesizer. Though for doing the same thing, I think the $options array may be a little simpler both to implement and [subjectively] use. Plus we're using similar $options arrays elsewhere in ProcessWire, so it'll maintain consistency there.

Good find, I just deleted all the spam pages. But then got into the user accounts and discovered we've got nearly 500 spam accounts in there, all with spam profiles. I don't know how to clear that out short of going through them individually 1 by 1, and don't want to spend the rest of the day doing that. Seems like MediaWiki might just need a little too much babysitting with the spammers. Unless somebody here knows how to administer MediaWiki (?), maybe we should just move the content that's there into the main site. And if anybody wants to submit new documentation, I can set them up with a ProcessWire account instead. I think MediaWiki was a good test, but doesn't seem like we're really using it for it's strengths enough to warrant keeping it. Though if anyone thinks we should keep it (and maybe knows how to clear out these spam accounts) that's fine with me too.

I think that the push-to-top/push-to-bottom buttons that Soma mentioned are your best bet, as that makes a simple job of moving an image to the top of bottom. But you'll need to save the page with the image on it before you'll get that option. As another alternative, you might try just reversing the order that they are output on the front-end of your site: foreach($page->images->reverse() as $image) { echo "<img src='{$img->url}' />"; }

Awesome update, thanks Wanze!

How about Atlanta at Piedmont Park: ProcessWire BeerBQ 2012… 8) on second thought, I think I'm the only one in all of Georgia using ProcessWire. I need to change that, but something called "Word Press" (?) is the buzzword around here.

That particular fieldtype (autocomplete) probably can't work on the front-end because it depends on an Ajax service from ProcessPageSearch. It might be possible to get it working if you are actually logged into PW admin at the time, but not sure if this is useful if you are trying to make it front-end.

I'm a little confused about what you mean by the 20% quality setting and how this relates to retina displays? I would think a 20% quality setting would look horrible, but obviously it doesn't (as your examples show). So I'm just scratching my head, not sure exactly what this is. Looking on my desktop (30" dell screen) the first image looks potentially a little sharper, though close call. Looking on my iPad or iPhone (both retina) the second image is visibly sharper (especially on the first example). Quite interesting to see the difference, though not sure I'd notice if they weren't actually side-by-side. Still, can't quite believe those are 15/25 quality, so scratching my head.

Here's a start on creating modules documentation. I still need to write a whole section on hooks, but it's fairly complete in other areas. Please feel free to edit/add to this. http://wiki.processwire.com/index.php/Module_Creation

For CSS files, there are 3 loaded on every admin request, but the load order is important, so only 2 of them could be potentially chunked (and the end of the load order): inputfields.css and ui.css. The same goes for JS files, where JqueryCore.js and JqueryUI.js could be chunked (at the top), and inputfields.js and main.js could be another chunk (at the bottom). Though I'm not sure there is enough to make it worthwhile, but definitely some room for experimentation.

I'm not sure there's enough context here to tell for sure, but the page where you are trying to add a file, try calling $page->of(false); just to make sure that the page in a state where it is ready to be saved. Also double check that the field you are calling on that page actually is a valid field name for the page. Beyond that, we might need a more specific example so I can attempt to duplicate myself.

Thanks for finding this elitLG! As you probably guessed, that's not the intended behavior-- you shouldn't have to calls setTrackChanges on your own. Thanks for the good example, I was able to duplicate here as well. I have updated the fieldtypeWakeupValue hook function in LanguageSupportFields.module to have the setTrackChanges(true) so that you don't need to do the above. This is now in the dev branch where it'll run through a little more testing just to make sure there aren't any side effects.

That's correct. If your file system has a limit like that, and you expect to have that large of a quantity of pages (which I don't think we've seen anyone do yet) then you'd probably want to only put file/image fields on the templates where you need them. If you have 60k+ pages, all with file/image fields, chances are you aren't editing them often, so you could also use this module to remove the directories.

I understand the benefits of combining CSS/JS files on a site. There are many places where they can be a real benefit, and fewer places where they may not. ProcessWire admin is one place where it wouldn't be a benefit. The issue with combining CSS or JS files with the PW admin is that the files are rarely the same between requests. It all depends on what process, inputfield and other modules are requested by the action. There could potentially be dozens, hundreds or thousands of different combinations (depending on your site). So combining these would be adding overhead rather than reducing it, as we'd be losing much of benefit of browser caching. Compare that to what we're doing now, where the browser can retrieve these files once, cache them and then use them in any combination without having to re-retrieve them every time the combination changes. ProcessWire loads things on-demand, so the selection of CSS/JS files in any request can change a lot. We want the browser to cache them individually so that they can continue to be used on every request without reloading.

Some recent additions for 2.3 that are now in the dev branch (I could use help testing if anyone has time): Added "required" support to all fields I've enabled required field support for all fields in ProcessWire (no need for advanced mode either). Now you get a "required" checkbox on the "input" tab of any field in Setup > Fields > [field]. If you are dealing with a published page and save it, you'll get an error if any required fields are blank. The page will still be saved. So it's more of something to annoy you into completing the required field. But if you are dealing with an unpublished page, it won't let you publish it (in the page editor) until you complete all required fields. While seemingly a small thing, the scope is more broad than it sounds as it applies to a lot of different Inputfields. I could use help testing this one out to make sure I haven't missed anything or introduced any new side effects or issues anywhere in ProcessWire. Other additions Fieldsets can now take advantage of column widths, enabling you to have multiple fields in a column. Fixed some bugs that occurred with fieldsets in tabs and fields getting brought into fieldsets they weren't supposed to. Add Interrobang's PHPdoc comments. Add ability to disable PW from throwing an exception when you call an unknown method (for porl's Twig module and other future ones like it). Clean up and optimize the /wire/templates-admin/styles/inputfields.css - it had some redundancy before. Also added a style to call out required fields. Other admin themes may want to do something similar (see the InputfieldStateRequired style in that file). Some other small things in the commit log (Apr 07-Apr 12)

I think that letter case for "n" might possibly cause this if statement to fail. It would have to be "NullPage" not "nullPage". But I agree with Antti that checking $page->id instead is probably easier and less prone to typos, etc.

@Pete, looks good to me. Earlier this morning I had plugged in something very similar into the default profile. I've just got it in the dev branch right now, along with a bunch of other updates.

This was there before I think, but I don't think it's what we want (?). It's the latest posts that people are looking for in this field rather than latest topics. Now it seems to be feeding us a combination: topics that have the latest post in them, but instead giving us the first post in the topic (which may be old). That seems confusing to me, which is why I left it out of the original feed. Ideally it would give us the actual latest post, but I didn't see that option in IPB. Seems like a strange omission? There must be some technical reason for it.

PW uses the .module extension for the same reason Drupal does... so that the file can quickly be identified (by PW's module loader) as a file containing a plugin module rather than some other PHP file. We've had a request to make it also support .module.php, so will likely be adding this shortly in the dev branch. But for now my suggestion would be to set your editor to recognize .module as a PHP file. For instance, I use VIM and place this in my .vimrc file: set nowrap syntax on au BufRead,BufNewFile *.module set filetype=php

The scope of Google Analytics is so broad, I don't think I'd ever expect something outside the GA app itself to implement it. Take the Real Time features for instance. You've done a great job of implementing the most important and most useful stuff. If I had to wish for anything it would only be that I could get more detail on the referrers. Like when I see a new referrer show up, I'd love to click to see the URL where the referring link actually exists. Sometimes I can't even do this in GA since it strips URL variables... leaving me to grep my access log to find the actual referring URL. But if there's some way to see not just the domain, but the path too, that would provide the same level of detail present in GA. I'm not sure what the best behavior would be here, as I'm guessing everyone has their own workflow and timeline they want to look at in GA. But I do know that the first thing I do when I get into GA is to set a date range. It's rare that I want to look at the last month or year. Usually I want the last 24 hours, last 2 days, last week, etc. I've often wished that GA had a select box where I could choose "last 24 hours" for instance, rather than having to select starting and ending dates.

I agree with Soma's reply. Also wanted to mention you could always register your own autoload function too. In my case, I either go the route of including a "tools.inc" file at the top of my templates that has all my shared functions (and/or classes if needed), or I use the module route as Soma mentioned.

Great update! I love the way it works with the tabs now. Not seeing the overflow issue anymore either. This covers about 90% of the things I use GA for. This module will get a lot of use for sure.

Good idea. I will plan to add this to the default profile too and we can recommend that people include the generator tag in their own sites...perhaps as a prerequisite to being listed in the upcoming PW site directory? This would make sense so that if the generator tag ever changes we know the site is probably not running PW anymore and shouldn't be linked from the directory.