Jump to content

Pete

Administrators
  • Posts

    4,054
  • Joined

  • Last visited

  • Days Won

    67

Everything posted by Pete

  1. I'm just checking up on threads I've not read yet (down to the last two pages now!) and noticed that http://www.tracktime-asia.com/ doesn't load for me - just thought you might want to know that Marty in case you're not already aware.
  2. Just a quick one, is this part of the core yet or is it due for inclusion in 2.3? Just curious, but I've not had a look at the latest build yet and I'm going from my mobile so can't test right now.
  3. Ah right, that core folder. Yup - either way you can overwrite the whole wire folder if you think there's something wrong with it without messing up the rest of your site which is handy.
  4. By "core" I guess you mean "wire". It does sound like something odd happened there but good to hear re-uploading it fixed things. Just a note on the admin folder - where Ryan said to rename the one in the site folder this would default to the admin theme in the wire folder then to rule out a custom theme issue. Basically keeping any custom modules or themes in the site directory means that you can simply overwrite the wire directory with a new version to upgrade without overwriting any custom modules or themes in the site directory - simple upgrade path
  5. Another way to do it could be some sort of paid support package, though there are pros and cons to that as you would need to offer something like "5 support tickets with 24 hour guaranteed response time" or something like that and you're only one person with other demands on your time. Plus it's nicer for queries to come through the forums so everyone benefits from the discussions. That said, might not be a bad idea for more corporate-based companies in the future where they need some sort of SLA. Don't mind me, I'm just rambling
  6. I wonder if this was only a browser-specific issue anyway? I know IE goes crazy when you miss out semicolons, but in other cases other browsers are fine with it.
  7. 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!
  8. 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?
  9. Could even have a different colour scheme for modules to avoid confusion (thus creating more work because that's just what Soma needs ).
  10. 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
  11. 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.
  12. Yup - I was also pleasantly surprised
  13. 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.
  14. 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.
  15. Pete

    A few sites

    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).
  16. 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
  17. 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.
  18. 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!
  19. 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
  20. Sounds interesting - are you able to share what you're using it for?
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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
×
×
  • Create New...