Pete

I quite liked the idea of an emulator actually as I didn't even realise until recently the problem with retina displays (even though I own an iPhone). I think some other manufacturers are using high density display as well nowadays but if using the emulator I'd only ever bother checking on the latest devices it supports - anything more than that will drive me crazy as I have a hard enough time getting things working in older versions of IE sometimes Interesting to see the other options though - very useful so if anyone has any more let us know!

Sounds useful - im guessing if a page's path changes twice the first path will be automatically redirected to the latest path, and not through any paths in between?

Could even have a different colour scheme for modules to avoid confusion (thus creating more work because that's just what Soma needs ).

Thanks both - this would be a useful thread to discuss any such integrations I guess ceberlin, as there are many scripts out there that had their own member systems. It will be good to see integration with another forum package too as we'll likely have different approaches to similar problems so good luck with it Thanks for your post ryan, that certainly gives me a good idea of how to do a few things I wasn't sure of

Might be easiest to have them on a drop down so it switches to a module-specific cheat sheet page. That said, now I think about it there aren't all that many modules that would have more than a handful of cheat sheet functions anyway.

Yup - I was also pleasantly surprised

Cufon essentially makes the words using a font as PNG images at runtime, whereas Fontsquirrel and others simply use actual font files, using CSS to present various file types depending on the browser being used. Looking forward to the new version but no rush.

You can shorten it a bit when excluding the current page to be id!=$page When you don't specifically pull out a field from a $page object it simply returns the ID. Not a lot of people know that, but it can be handy.

Nice sites Glad to see you've used lots of fields too - makes me feel a bit easier about having done it myself too even though I already know it's fine to do so as long as the template code is sensible (I always worry my code isn't as streamlined as it should be at times, but I'm just happy when it works).

It looks like in your example you simply want to get the value of all pages created using that Page field? I thought they were always under the same parent/template unless you used a custom selector when setting up your field, so if this isn't what you want: $pagelist = $pages->find('/path/to/parentnode/')->children(); then maybe this? $pagelist = $pages->find('template=yourtemplate'); Other than that, if you used a custom selector when setting up your page field then you would simply use that selector again inside your template code. Unless of course I've not understood what you're after

I think you've made an excellent point there - as long as it's easy to find the right module, we won't get near-duplicate modules appearing unnecessarily. Similar modules should theoretically only appear when there's a good case for them to be made, such as a different specific use or something like that.

Okay, so I've only just read this thread (I've been busy elsewhere ) so ryan is probably getting sick of the fact I've "liked" every other post in this thread in the last five minutes, but I do like it For mobile testing, you might like to try this ryan: Also, just my personal preference, but I've gone completely off Cufon in recent months and prefer to use the likes of FontSquirrel. I know it's down to personal preference from the designer's point of view, but it did occur to me that if you supported something like a standard site/templates/fonts folder then you could ship several fonts from fontsquirrel with the default theme (they're free) and even support dropping new fonts into that folder and have it tied in with a drop-down font selector in the admin area somehow. Just a thought, but I think something simple like that could be reasonably easy to implement for the benefit of non-web-savvy users. I love everything else about this and will be digging through the code at some point to see where I can use bits on some of my current sites, as well as using the whole thing for future sites. Keep up the awesome work!

I'm sure someone may already have posted this somewhere but I've only just come across it myself: http://www.opera.com/developer/tools/mobile/ Very handy as I only have an iPhone to test mobile sites on, plus this will test some tablet sizes too

Sounds interesting - are you able to share what you're using it for?

He never mentioned repeaters, but they certainly are one option, especially for the startlists if I understand that one right. It's definintely possible to do all of this with the Page fieldtype and a few templates. Things like the Nationalities could even be one of those Page fieldtypes where the user can add new entries to the list from Riders template for example, though you have to bear in mind that you can only add a title that way and you'd have to add the code afterwards. Might just be easier to populate the nationalities in advance and have it as an autocomplete field instead. I don't think you would really have a problem with any of this in PW. Looking at your diagram, every table there is simply a different template and all you have to worry about is how to make them work together.

I've got some integration with IP.Board running here: http://www.strategycore.co.uk In fact, the user strip across the top outside the forums is through a PW module that accesses functionality of IP.Board, plus all commenting in news and articles on that site uses some IP.Board functions in a PW module too along with my own code so they can add replies from the article pages themselves. There are a few things to note though: It's not exactly what you're after - I didn't bother trying to somehow link the permissions as that always gets messy when the forum software gets rewritten, plus it's rarely the case that your member groups will be the same on the forums as they will in your PW installation (if you have many moderators looking after your forums, do you really want them all to have the same perms in PW?) It doesn't do single sign-on. I do have something in mind, in that when someone tries to login to the PW backend using IP.Board login details, it sets up an account for them in PW with the same password. This doesn't give two-way authentication of course, but it doesn't matter really as if you're always authenticating against the forum software first then you simply check if any details have changed from the forum user account and update them on the PW user account with the same name before logging them in. Once an account is created, whenever they next log in on the forums and browse to the site, PW can do a quick check to see if a PW account exists with the same name, create one if not and log them in quietly behind the scenes. This then allows an admin to place their PW user account, which would be a guest account by default, into another group for PW on a per-user basis With the way my module currently works, I've tried to simply use core functions from the forum software. The API for IP.Board is a bit limited so I simply ended up initialising the forum software from my PW module and using the forum's classes from there, minimising the amount of custom code I was throwing into the mix so that it should survive all but major updates (you're always at the mercy of forum software when connecting other scripts to them as they roll code out so often). I'm still not happy that my module would survive a major upgrade to the forum software, as not every project is as thoughtful as PW about keeping deprecated functions in place for a while, and some change class and function names far too often, but I'm reasonably sure that my code should work for the life of IPB 3.x (min version is 3.2). So anyway, I approached my module from the website being the core, not the forums (although forums are often the core in terms of community). This is because it seems far easier to override PW's functionality than IP.Board's, and I think the same would be true of other forum software. There are already a few examples of other sign-in methods on the forums here for PW (the LDAP login module was the one that showed me how easy it is to override the normal login routine). Just some food for thought. Whichever forum software you use, none of them seem to have amazing APIs and others aren't even possible to bootstrap so there's that to bear in mind.

Hey chaps I've implemented the syntax-highlighting extension, not that it works automatically unfortunately. You can get an idea of how it works by editing the wiki page SiNNuT created and look at the tags wrapping the code. I probably went overboard adding the line numbers to some of the one-liner bits of code, but thought it best to leave it in for now until people have a look at it.

I think comments and pager should be too - they'd both be useful or blog/news/magazine sites and that's a large portion of the web right there. Although if there are lots of things to add for these core modules then perhaps they should go under a separate page for modules, and maybe separated by module type? Might be getting a bit too complicated there but it's an idea.

I agree diogo - a lot of other systems seem to have half a dozen gallery modules for example and not all are great galleries or offer different functionality that could be merged together into amore coherent module. In those cases and others, expanding on existing modules (whenever the author doesn't mind) would be preferable than reinventing something completely. For example, if someone creates a gallery module with a specific lightbox script and someone wants a gallery with a different lightbox script, it could just as easily be implemented by altering a few lines of code and adding it as a configuration option. Also, it often (though not always) turns out that as modules grow in this way with several developers pushing things forwards you end up with a much more mature piece of code as a result. Of course, that depends on whether the devs can agree, but that's where version control and Github comes in with the original author retaining overall control and merging changes to the source

I'd personally go for building the profile editing page yourself - your list of fields doesn't sound very hard to implement and you'd have more control over how it looks.

I moved from MODx to PW and wouldn't want to move back. Don't get me wrong, MODx (Evo) was a great tool and really useful, but to do anything more complex you have to learn their markup and terms whereas PW doesn't force you to work any particular way. As such, I suspect all of my MODx sites will eventually be moved to PW - the point they make the switch for each will be the point at which being on MODx becomes a restriction (at present, they work so if it ain't broke...). Sorry, I'm not adding much here but since the only other project I currently work on is an intranet system that's home-grown and I can't think of another system I'd need to use besides PW for everything else. That said, I'm getting into Lemonstand for an e-commerce site at present. It's a little bit of a learning curve as they don't have a cheatsheet (ever project should have one since I'm so reliant on Soma's ) but there is great flexibility to be had behind the scenes. They could do with changing their coding to a jQuery style (because I'm lazy) but aside from that if it doesn't have what you need it's easy enough to program something, as well as being easy enough to create custom calls to the database.

If you do have entries in yor list for every year though then the suggestion from another post would be to simply find your oldest article instead of iterating trough all of them and simply start your years from there to the current year, or even hardcode it into the template. If I did have an article for every ear, I'd probably hardcode the start and check the date of the latest article instead - not everyone manages to pen an article on January the 1st as some of us wake up feeling a bit groggy

I found it. Well, the troublesome script at least. I changed this line in wire/core/ProcessWire.php: $logMessage = "Page: $path\nUser: $userName\n\n" . str_replace(" ", "\n", $message); to this: $logMessage = "Request: " . $_SERVER['REQUEST_URI'] . "\nPage: $path\nUser: $userName\n\n" . str_replace(" ", "\n", $message); @ ryan, looking again at the error code in that file, wouldn't it be better if this: $path = ($config ? $config->httpHost : '') . ($page ? $page->url : '/?/'); was actually this: $path = ($config ? $config->httpHost : '') . ($page ? $page->url : $_SERVER['REQUEST_URI']); to potentially give a bit more info, or is there a reason why the fallback is set to /?/?

I've been noticing this message come up recently at random - sometimes several at a time and sometimes spread out a lot. I updated the wire directory and it still happens, however I was wondering if anyone could shed some light on what it actually means, or suggest a way to determine where the problem is? 2012-05-31 03:36:51 guest http://www.mysite.co.uk/?/ Error Exception: Can't save page 0: : Pages of type NullPage are not saveable (in /home/strategy/public_html/wire/core/Pages.php line 463) It's almost certainly an issue with something I've coded, but for the life of me I can't think where to look and I can't reproduce it myself whether I'm logged in or not.

Well somewhere between not that much and every day. Maybe a few times a week. After a while some of it sticks (or so I tell myself), so I don't ened to refer to it all the time It is invaluable though for when I draw a blank and want to check whetner I can do something a certain way.