Jump to content

Community

Feld0

+Clients
  • Posts

    442
  • Joined

 Content Type 

Profiles

Downloads

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Store

Everything posted by Feld0

  1. The "Flag as spammer" button in the admin area makes it too easy to wreck a user's account, with no just-as-easy path to undoing it. A single click disables the account and hides all of its content, and clicking the "un-flag as spammer" button does not roll most of it back. I'm opening this thread today after accidentally clicking flagging a user led to manually going through a user's entire post history to unhide everything. With how easy and destructive it is to perform the "flag as spammer" action, to protect against accidents, I'm requesting that the "un-flag as spammer" button be improved to fully undo the "flag as spammer" action. Alternatively, the "flag as spammer" button could be modified to require a confirmation, with a warning that the action cannot be easily undone.
  2. +1 for "pay what you want" pricing for store items - that would be incredibly useful as a way to let users donate an amount they decide to our site on a monthly basis.
  3. We found that when a user is banned from a topic, if they were following it, they still receive notifications from it. Could this behaviour be changed?
  4. 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.
  5. 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:
  6. Docs are there: :smile: http://www.invisionpower.com/support/guides/_/advanced-and-developers/ipnexus/how-to-interact-with-purchases-r113 http://www.invisionpower.com/support/guides/_/advanced-and-developers/ipnexus/itemsphp-extension-file-r134 http://www.invisionpower.com/support/guides/_/advanced-and-developers/ipnexus/actionsphp-extension-file-r133 And I believe IP.Downloads makes use of these same API's, so a source dive there might reveal some hints. Think you might have an ETA on the next update? If it's still a bit far out, I might take a crack at building a Nexus gateway myself.
  7. Hi Mike, Any update on the implementation of the IP.Nexus gateway? Having completely different payment systems for donations and the store on my site is confusing to some of my users. The Nexus gateway would make things a lot more consistent for them, and give them alternatives to PayPal as well.
  8. 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.
  9. +1. This suggestion came up in one of my own communities, and it would be great to see it implemented.
  10. +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.
  11. 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.
  12. Looks like it. :O Thanks for the link, Marcher - I was unaware that the fix existed. Down to just 8 queries now. :D
  13. 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?
  14. 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.
  15. Feld0

    TracDown

    Here's my guest permission set: It appears to be correctly configured for me; however, the issues in my site are accessible by direct URL (I can PM you with an example if needed).
  16. Feld0

    TracDown

    It appears that TracDown's permissions aren't programmed correctly. Most of our bug tracker is configured to be viewable only to specific groups, but every issue is visible to guests. The category pages are not, as intended, but the issues they contain are accessible by direct URL and made it into Google's index.
  17. 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.
  18. 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.
  19. 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.
  20. CSS sprites don't need to come at the cost of losing the ability to easily edit a skin's icons. A tool can be implemented to automatically generate a sprite for your theme from a set of icon files. A number of such tools already exist, and XenForo has one built right in. I think that would be a very reasonable feature to implement. :)
  21. Beneath the surface, does the new database class use PDO or the mysqli_ library? How about providing a Sphinx driver for everything that requires a fulltext index? :smile:
  22. I personally prefer Zurb Foundation, which I just switched to in an application I'm working on. Bootstrap is hugely popular, but Foundation's grid feels much more intuitive to work with, particularly with the way its nested columns work. If IP.Suite 4.0 adopts a third-party HTML/CSS framework, that's the one I'd like to see. IPS's developers aren't afraid to get their hands dirty and build their own frameworks, which is awesome, but they also went ahead and committed to CKEditor for their WYSIWYG needs as they found it already delivered most of what they needed, so it's clear that they aren't averse to using third-party code where it makes sense. Frameworks are rigorously tested to deliver their grids and features reliably on a wide range of browsers, and I recall that was the main reason CKEditor was adopted. Even then, the main advantage I see coming out of adopting a framework like Bootstrap or Foundation is the wealth of community resources for those frameworks that IP.Suite webmasters would get at their disposal. I certainly wouldn't mind that. :D
  23. Thanks. Applied your fix and it works great. :) There was a slight correction I had to make, though: the latestDonationsSidebar template bit is in the skin_donate_external group, not skin_donate. There's another issue I've run into: when using friendly URL's, entering the wrong slug for a goal doesn't trigger a 301 redirect like forum topics and such do. This would be useful for preventing any duplicate content issues.
  24. Hi Mike, I recently upgraded to the new version of the app that you just released and one of our members found a rather nasty bug with it. Namely, if a member marks a donation as anonymous, their avatar is displayed beside the donation on goal pages and is linked to their profile.
  25. The "wiki-style edits" database option controls whether every member with the "edit records" permission can edit a record, or only the record's creator and any relevant moderators. This is configurable.
×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy