• Content count

  • Joined

  • Last visited

About Feld0

  • Rank
    Advanced Member

Recent Profile Visitors

8,475 profile views
  1. This is possible, but note that all changes to the individual club forums (the sections in them, permissions, group members) will need to be done by a forum administrator, as there's no way to limit the control of this further than the ability to manage all forums, the ability to manage all groups, or the ability to manage all permission sets. IP.Board does not have a concept of "section admins" who can manage a specific area but not the rest of the site. For what it's worth, this isn't a feature I've seen in any of the other major forum packages, either. If your administrative staff are active, it's workable. :)
  2. Host external pictures

    It uses a lot of storage, but from personal experience, I think it's well worth it. If you're running a large site with loads of activity, you're probably on dedicated hardware anyway, for which storage is pretty cheap. :) I'd love to see this in the core, but considering the server requirements it comes with, it might qualify as a "niche" feature. That said, forums are all about content, and images are a huge part of that. One might as well say that attachments are "niche" because free file hosting services exist that someone could easily link to instead, but attachments last as long as the forum does.
  3. A member brought an issue to my attention today which allows users to easily bypass their group's signature image size restrictions. When a member sets up their signature, IP.Board will check the dimensions of any embedded images to ensure they fit within the restrictions. However, if an image is embedded into a signature and is subsequently replaced by a larger one at the same URL which breaks the size restrictions, IP.Board will not react to it in any way, and will happily let the new image stay. Re-checking the image on every pageview would create some pretty bad resource issues, but... fortunately, there's a way to work around it. :smile: Avatars used to be prone to the same issue, but they were neatly fixed when the option for a "remote" avatar was modified to download the remote image to local storage after a one-time size check, where users can't touch it anymore. The same could be done for signatures - copy images to local storage after checking they fit the restrictions. Even better would be an option to upload signature images to the forum directly, if they're going to be copied to the server anyway. :smile:
  4. If a donation goal in IP.Nexus has been reached or surpassed, the button to donate towards it disappears (strangely, this does not appear to affect administrators; I'm working out whether that's a bug or not with IPS right now). The only way around this is to raise the goal amount or remove it entirely. Raising the goal amount may not always be appropriate, and removing the goal amount also hides the counter showing how much has been donated, which can bring up accountability concerns when asking a community to raise money for a cause. But it's not uncommon for people to want to "overcontribute" to a cause (Kickstarter is a very strong example of this), and there's no way to accommodate that with Nexus while keeping the original goal amount visible - users like to know how much they overshoot it by! I suggest either removing this behaviour, which would make it so that the only way to disallow donations to a goal is to remove it; or adding an option in the ACP to let admins configure whether they want contributions to be cut off once the goal is reached. The latter would be preferable, but the former would be an acceptable compromise if adding another option to the ACP presents an issue.
  5. Request: Browser Agent for Support Requests

    +1. This would be really useful. :)
  6. Notification when a post is approved

    Awesome! Thanks, Adriano. :) But it's only for topics - any chance you could add notifications for approved posts to the hook as well (or perhaps in a new hook)? That would be really useful for forums where individual replies to topics need to be approved.
  7. Notification when a post is approved

    +1. This suggestion came up in one of my own communities, and it would be great to see it implemented.
  8. +1. The ability to whitelist specific domains for dofollowing would be excellent for me, as I'm building a larger network of websites for my members, and expect an awful lot of links to the rest of the network to pop onto the forums in due time.
  9. Use a third party library/framework, or build it in-house?

      I'm developing a new application using Foundation. Originally used Bootstrap because that's the framework everyone talks about, but when I discovered Foundation, the better grid (every column becomes its own twelve-column grid) won me over, so I switched. That, and I like that it's less opinionated about how your site should visually look, since my app needs to have a distinct design for the users' enjoyment anyway.
  10. Looks like it. :O Thanks for the link, Marcher - I was unaware that the fix existed. Down to just 8 queries now. :D
  11. Some development decisions made prior to 4.0

      Thirded. :smile:     I understand why you choose PHP 5.3 as your lowest supported PHP version. 5.4 is already supported by cPanel, however, and it is only going to spread in the time you take to release IP.Suite 4.0. I just hope it doesn't hamper your development too much, as 5.4's new playthings are excellent. Any chance you might bump up your minimum required version at some point during the 4.0 lifecycle, or can we count on PHP 5.3 remaining the baseline until 5.x?
  12. In its current design, IP.Board runs the following query once for every single member in the Currently Online list (replacing the "3479" at the end with the ID of each active member, of course): SELECT m.*, m.member_id as my_member_id,p.*,pp.*,g.*,ccb.cache_content FROM members m LEFT JOIN pfields_content p ON ( p.member_id=m.member_id ) LEFT JOIN profile_portal pp ON ( pp.pp_member_id=m.member_id ) LEFT JOIN groups g ON ( g.g_id=m.member_group_id ) LEFT JOIN content_cache_sigs ccb ON ( ccb.cache_content_id=m.member_id ) WHERE m.member_id=3479 It would be sensible to refactor the feature to use eager loading to grab all the members in a single query, no matter how many of them there are: SELECT m.*, m.member_id as my_member_id,p.*,pp.*,g.*,ccb.cache_content FROM members m LEFT JOIN pfields_content p ON ( p.member_id=m.member_id ) LEFT JOIN profile_portal pp ON ( pp.pp_member_id=m.member_id ) LEFT JOIN groups g ON ( g.g_id=m.member_group_id ) LEFT JOIN content_cache_sigs ccb ON ( ccb.cache_content_id=m.member_id ) WHERE m.member_id IN (3479, 5654, 4543, 6576, 8695, ...) The online list alone is responsible for adding well over a hundred queries to our index. Disabling it made it come up a good half-second faster. All these queries add a great deal more traffic and overhead to the database connection than there needs to be.
  13. Where are the large IPB 3.x + websites?

    It's not a "mega" forum, but it's definitely a "big board". 1.2+ million posts and 10,600 members in 17 months isn't too shabby if you ask me. :) MLP Forums has been on IP.Board since day 1. Many of my earliest members actually informed me that part of the reason they gave the site a chance in its early days was because it felt extremely modern and user-friendly, and we've done a lot of custom development since to improve this even further. We've never had an SEO problem and consistently rank #1 or somewhere near it for many search terms in our niche.
  14. A pet peeve I have with the 3.x series of IPS apps is the lack of a standardized naming convention for tables and columns in the database schema. This is a mostly cosmetic change, yes, but making them adhere to some naming conventions would make them a great deal more human-friendly to work with - which usually means happier developers. ;) For example, depending on which table you're looking in, you might find a user's account ID referred to as "member", "member_id", "mid", "author_id", "ps_member", "i_member", "log_member", "comment_by", "report_by", or a slew of other names. Topic ID's are referred to as everything from "tid" to "topic_id" to "exdat2". This lack of convention stretches through every app's schema. It's mostly foreign and primary keys that stand to benefit from this. One convention I'm a fan of is calling a table's primary key "id", and foreign keys referring to it "{singular}_id". So instead of letting each table have its own idea of how to reference a topic ID, they could all be, simply, "topic_id". In some tables, column names have enigmatic abbreviations that don't make their purpose particularly obvious - like "can_mm" on the "moderators" table. That column could be renamed to "can_multimod" and suddenly becomes much easier to understand. Sometimes, even the column names within a single table are really inconsistent. Look at the schema of the "moderators" table for a prime example - most of its columns hold what amounts to a simple boolean value denoting whether a moderator can or cannot perform an action. The way it is, one column is prefixed with "can_", two with "mod_can_", one with "allow_", and most don't have a prefix at all. Wouldn't it make some sense to standardize all these columns to be simply prefixed with "can_"? And sometimes, prefixes are used in places where they serve no clear purpose. Every single column in the "nexus_ads" table, for example, is prefixed with "ad_", which isn't particularly meaningful when the entire table only contains ad data. The "ad_id" and "ad_locations" columns in the "nexus_ads" table would still be just as meaningful if they were called "id" and "locations". Again, I realize that a site's users never have to see any part of the database schema, but developers sure do. Applications will have to be largely refactored to function on IP.Suite 4.0 anyway, so this is a rare opportunity to make breaking changes to the schema.
  15. I decided to give the auto-upgrader a chance for the latest round of maintenance upgrades, and I have to say that I was pleasantly surprised by how smooth the process was! Really love what you've done here, IPS devs. :thumbsup: I had only one gripe with the process... it overwrote my favicons! :ohmy: I had to manually upload those back to my server after the auto-upgrade, which put a damper on the experience. If you could tweak the upgrader to skip uploading the default favicon.ico, that would be a small, but very appreciated, improvement.