• Content count

  • Joined

  • Last visited


About alexp999

  • Rank
    Spam Happy

IPS Marketplace

  • Resources Contributor Total file submissions: 6
  1. Post Edit History - REALLY NEED THIS

    Any news if this is being implemented for IPB 4.0?
  2. Website with multiple forums

    You can also set a different skin per forum, so for each category have a different skin to make them each look/feel unique.
  3. Compound Profile Fields

    I've used "display: inline-block" on a couple of elements, although they still go through a hook. Just means I can stick them next to each other.
  4. Compound Profile Fields

    In topic view, could you just not alter the CSS so they display inline?
  5. Dates in Cached Feed Blocks

    I ended up making my own solution to this in the end. Wrote a plugin to grab the data and strip out all the fields I don't need and cache it, then another block which is not cached which grabs that cached data and converts it to the output and correct time for each user.
  6. (tng34) Custom Profile Field Dropdown

      In the example on my website. The custom fields are configured and only appear when a user enters the information for it.   This is not a hook for grabbing system spec information, that would require a java app and heavy integration.   It is for displaying groups of custom profile fields as dropdowns. I have just used System Specs as an example from my website. :)
  7. For anyone coming across this later on, I'm pleased to say my hook is not needed for IPB 3.4.x, as IPS have implemented this fix themselves :)
  8. Introducing IPS Backup Service

    I assume this is for database only, so in the event you loose everything, all attachments/uploads, etc would still be lost?
  9. Suggestion - Cache Query but not Block

    I havent stripped anything from the array, its serialized the entire $records array. I might look into stripping what I dont need. I imagine its only going to affect how quickly the server reaches max capacity as I cant see how the page can load any faster than it already does.
  10. Made a free hook you can use, until this becomes part of IPB: Alex.
  11. Suggestion - Cache Query but not Block

    I misuderstood what you meant by heavy cleaning then :/
  12. Version 1.0.0


    Exactly as the title says, this hook aims to improve upon the "Anti-Cache Hash" which IP.Board now has to try and stop web browsers caching old CSS and javascript files. IP.Board's default implementation will only ever realistically change the hash when upgrading to a new version of IP.Board. This is not ideal, especially when you make changes to your skins as the changes will not be reflected without everyone who visits your site, first clearing their browser cache. What this very lightweight and simple hook does, is replace all instances of the hash with another one (based on the original hash), but it will change based on the timestamp of when the skin the user is viewing was last updated. You may find you need to re-cache the skin after editing it, to force the timestamp to update if you do not see your CSS changes straight away. Basically, if you are having issues with CSS changes not making it to your users without them clearing their browser cache, give this hook a try and get behind our feedback thread for getting something like this added to a future IP.Board release:    IPB 3.4.x   I'm pleased to say this is not needed for IPB 3.4.x, as IPS have implemented this fix themselves :smile:


  13. Suggestion - Cache Query but not Block

    I've got 4 blocks with 10 rows each stored serialized and it is still considerably quicker than no caching at all.
  14. The only fix until its included in a future release will either be a code modification or hook. I was hoping me might get some input from IPS on it too, but I think I will have to look into writing my own hook for now.
  15. I opened a support ticket after I found that CSS changes weren't visible on my site, despite there being an anti-cache hash. It seemed as though the hash was not changing even after re-caching the skin set, so I dug into the output class and found the following: $this->antiCacheHash = md5( IPB_VERSION . $this->settings['board_url'] . md5( $this->settings['sql_tbl_prefix'] . $this->settings['sql_pass'] ) ); Which means that its fairly pointless, as it will only realistically change when the site owner updates their board. The hash should change whenever the skin is updated. I had a look through the core caches, and we already have a cache entry for each skin in "skinsets" under "set_updated". I would imagine its a very simple change, that requires no extra queries, to have the timestamp of when the skin was last updated added to the hash, then whenever someone edits their skin files, changes will be reflected straight away as the hash will change.