Jump to content

Fast Lane!

Clients
  • Posts

    925
  • Joined

  • Last visited

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Posts posted by Fast Lane!

  1. 6 minutes ago, opentype said:

    I don’t appreciate leading questions like that. 
    If you would say “let’s reduce environmental pollution with measure ’X’“ and I point out that measure X might not work properly and might cause other issues, it would be naive at best or even dishonest to ask “so you don’t want to reduce pollution?” It just doesn’t logically follow. I addressed a specific measure/hack and explained my concerns. I have nothing more to add. 

    I was not trying to rub ya wrong :).  Big hugs.  Just trying to understand where the practical (realized) downside is here versus theory.  You said "then after the page is loaded, you say “April fools! Now switch to the webfont!" -- however as mentioned, the font actually swaps once the resource is loaded which for me appears to be pre-render (not after the page loads) so there is no practical issue other than the benefit of the reduced render timeline and FCP (due to no blocking).

    What am I missing here?

  2. You'd prefer a 0.7s rendering delay (until it is cached)?  Btw I don't see any issue with the swap (hence the display=swap param in the current font call which it's doing already).  Also, let's be practical.  For my site (at least) the page hasn't even rendered yet so there is no visible font swap (and the time to render was reduced with this change).

    There was a second option -- to inline the Google font styles rather wait for them to be fetched (which is the 0.7s delay).

    2 hours ago, opentype said:

    then after the page is loaded

    It does not wait until the page is loaded.  It just waits until the resource is loaded.  It's extremely quick up front and at least in my testing not visible to the user.

  3. First, all the credit to this site (Wordpress folks... no surprise!): 

    Here is the fix to save 0.7s due to render blocking (and it is a big one for anyone using a google font which I think is the default.  This should probably just be a permanent update by IPB 🙂 IMO.  It's so minor (and the linked page goes into the details).

    In the includeCSS template.  Change this:

    <link href="https://fonts.googleapis.com/css2?family={expression="\IPS\Http\Url::encodeComponent( \IPS\Http\Url::COMPONENT_FRAGMENT, \IPS\Theme::i()->settings['body_font'] )"}:wght@300;400;500;600;700&display=swap" rel="stylesheet">

    to this:

    <link href="https://fonts.googleapis.com/css2?family={expression="\IPS\Http\Url::encodeComponent( \IPS\Http\Url::COMPONENT_FRAGMENT, \IPS\Theme::i()->settings['body_font'] )"}:wght@300;400;500;600;700&display=swap" rel="stylesheet" media="print" onload="this.media='all'">

    This is the specific difference which is quite minor: media="print" onload="this.media='all'"

    This was before:

    Could contain: Page, Text, File

    And after it's totally gone :).  The improvement is significant... with before:

    Could contain: Text, Number, Symbol

    and after (0.7s faster!):

    Could contain: Text, Number, Symbol

    I tried this other fix but it was a bit hacky, requiring inlining the Google font css (the issue).  It does work as well... just less elegant as above.

    Note: I have ton's of other things that slow my site down (ads / header bidding, etc...) but the relative improvement is awesome!  This is not just faking Google Pagespeed ratings...  this is a legit 0.7s reduced pageload time for the first page view.

    Thanks... hope this helps others. @Matt and team IPB.  You are welcome to use (hopefully) or not :P.  I linked to all references on the "why's" of the technical implementation.

  4. 20 minutes ago, opentype said:

    If necessary, one can change the language string to clarify that this does not include posts. 

    I have it in my terms of service that personal data should never be included in posts and that account deletions will not delete posts. So users agree to that. If personal data ends up in individual posts, I deal with that on a case-by-case basis and delete the personal data or the entire post. But it makes little sense to delete possibly thousands of posts just because there is a chance that one of these posts could contain something personal. 

    Fwiw, simply having the option for admins to use doesn't mean we need to "always" use it (what I'm discussing is simply having the option).  It's just that -- an option to select when approving an account deletion.  As an aside may be nice to have the member enter a "reason" why they are requesting their account to be deleted.  That may guide us.

  5. 5 hours ago, Adriano Faria said:

    Nope. Personal data is the user name, email address, photo, IPs, etc. Content isn’t personal.

    Disagree, in some cases.  See: https://gdpr.eu/eu-gdpr-personal-data/

    This data can easily be contained within posts.  It's an assumption that a member did not post PII in their posts -- ever.  In fact, in many cases members request account and content deletion because they over shared information over time like their email, address or legal status in their posted content.

    If as an admin you take the position to not delete that information (anonymize content) that is a right, but not a protection.  Should there have been PII in that posted content that remains then the 'right to delete' provision (and protections against) may be challenged. 

    My request was to give the admin the option to make that decision, based on the uniqueness of each situation.  Anonymize or delete posted content.  I get it -- deleting content can reduce site content, but that is second to compliance.

  6. +1 

    The fact that the posts remain and the user name is simply changed to (effectively) now guest is not at all the behavior that the actual tools presents to the user.

    Could contain: Text, Page

     

    This explicitly states that the content is deleted.  There are many cases where the is PII in the content which is what the member wants purged.  Shifting the content to a guest feels misleading and would make it even harder to find later to purge.

     

    **Note: I think in most cases the default (current) approach is the baseline action.  However in some cases actually purging content (at the admins decision level) is appropriate.

  7. 7 hours ago, Daniel F said:

    That's already happening once the "Hide content submitted already" or "Delete content submitted already" option is enabled

    See my photo above.  The customer field content is still visible despite the member being flagged as a spammer.  I think we have the option set to "hide content" since mods have mistakenly deleted accounts before when flagging as a spammer by accident (hiding is a reversible action worse case).  If this is the issue can we hide the profile custom fields as well?

  8. I think a good improvement here would be for the flag as spammer action to clear profile fields, member photo and custom field data as well.  If not their profile will remain as a spam billboard (see above).  

    Maybe another complementary option would be to simply have spammed flagged profile not be visible publicly (even the user name is often SEO crafted).

  9. 2 hours ago, Marc Stridgen said:

    They are present only to give someone chance to register and associate with that content. But it is removed if they dont.

    The challenge for mods (high praise to them) is the volume of spam in pink (hidden) on the forums is so large that it’s like a checker board. Hard for admin/mods to make heads or tails of it and separate other hidden content in a mod queue. Last I checked it was all visible to us (maybe not members).  If it was simply hidden from everyone including mods that may be more elegant. 

  10. 14 hours ago, amoncur said:

    @DawPi Thank you!

    @Fast Lane! Are you saying disabling "Post Before Registering" is a spam magnet? Or enabling it is?

    Enabling post before register will add bloat to your site and add link everywhere for unapproved spam posts. That’s our experience at least. If you use hiding other content as a tool things get lost easily.  

  11. 16 hours ago, Gabriel Torres said:

     @Marc Stridgen At least here with us, we are always looking into ways to reduce the size of our database and pruning unecessary data. Our community for 20 years now, so you can imagine the size of everything here. In our case specifically, we think we can do a nice cleanup by pruning old spammers (e.g. over 1 year ago) and their offending posts/topics.

    Banned users are a different case, however, with new privacy laws in our country, it is always a concern to keep personal data from these users...

    Adding to this.  Banned members for us include spammers which may have left nasty images and such in their profile fields (visible on their profile) without having posted anything on the site.  I’m sure other admins have had this (SEO member names with random profile spam).  Flagging them does not remove this content.  We prefer to clean up those banned members which include lots of spammers for us.  

    Just like the prior poster. We’ve been with IPB for 20+ years and tens of millions of posts. Hopefully we have something to add. Right now around 50% of signups are SEO profile spam accounts that never post.  It’s silly and I refuse to fully lock down members their first day or two and drive new folks away with a bad experience.  Credit to our mods who review new accounts daily for this. 

×
×
  • Create New...