Blog Post

Apg Vnext 50 Mobile Phone Upload Ie11 Compatibility And More

Apg Vnext 50 Mobile Phone Upload Ie11 Compatibility And More — release and upgrade information for APG vNext 50.

Upgrading APG vNext

  • Back up your SQL Server database before starting any upgrade.
  • Save your web.config, custom skins, and upfiles folder contents.
  • Run the upgrade SQL scripts in sequential order — never skip versions.
  • Test all key features after upgrading: login, posting, email notifications, file uploads.

Download & Support

APG vNext 5.0 — The Major Version Milestone (upgrade and deployment perspective)

APG vNext 5.0 represented the most significant version bump since the vNext rewrite. The two headline features — mobile device file upload and Internet Explorer 11 compatibility — addressed the two most common complaints from communities whose members were shifting to mobile-first browsing in the mid-2010s. The "and more" in the release title covered a substantial list of improvements accumulated from the 4.x feedback cycle.

Mobile Phone File Upload

Prior to 5.0, attaching photos from a mobile phone required the desktop version of the browser or a third-party workaround. The mobile upload limitation was rooted in the HTML file input control's behaviour on iOS and Android WebView — specifically, the accept attribute for camera capture was not supported in the APG vNext 4.x upload control.

APG vNext 5.0 replaced the legacy file input with an HTML5-compliant upload control that:

  • Supports accept="image/*;capture=camera" on mobile browsers
  • Allows selection from the device gallery (not just the camera)
  • Performs client-side image size validation before upload to reduce server load
  • Shows an upload progress indicator — critical for mobile connections with variable speed
<!-- APG vNext 5.0 upload control configuration in web.config -->
<appSettings>
  <add key="APG.Upload.MaxSizeMB"      value="10" />
  <add key="APG.Upload.AllowedTypes"   value="jpg,jpeg,png,gif,pdf,zip" />
  <add key="APG.Upload.MobileCompress" value="true" />
  <add key="APG.Upload.ThumbWidth"     value="800" />
</appSettings>

Internet Explorer 11 Compatibility

IE11 compatibility in 5.0 was not simply a CSS fix — it required replacing several JavaScript components that relied on ES6 features unavailable in IE11 (arrow functions, template literals, Promise, fetch). The 5.0 build process added a Babel transpilation step for the JavaScript bundle and replaced the fetch API calls with an XMLHttpRequest polyfill for IE11 detection.

If you are running APG vNext 5.0 and still see IE11 issues, check that your IIS is sending the correct X-UA-Compatible header:

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="X-UA-Compatible" value="IE=edge" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Migrating From APG vNext 4.x to 5.0

The 4.x → 5.0 upgrade is a major version jump and carries more risk than a minor version upgrade. Plan for a maintenance window of 1–2 hours and follow the migration guide precisely.

Breaking Changes in 5.0

  • Custom skin files from 4.x are not compatible with 5.0. You must port CSS customisations manually to the 5.0 skin structure
  • The upfiles folder structure changed — a migration script moves existing attachments to the new path
  • Three deprecated admin API endpoints removed; custom plugins using those endpoints need updating

Upgrade Sequence

  1. Upgrade to APG vNext 4.5 first if not already on it
  2. Back up database with BACKUP DATABASE ... WITH COMPRESSION
  3. Back up full application directory including all skin files
  4. Deploy 5.0 application files to a staging environment first
  5. Run upgrade_4.5_to_5.0.sql against the staging database copy
  6. Test all core functions: post, upload, login, email, search, moderation
  7. Port CSS customisations to the 5.0 skin
  8. Run migration script for upfiles folder restructure
  9. Deploy to production during low-traffic window

Skin Migration from APG vNext 4.x to 5.0

The skin system in APG vNext 5.0 was rebuilt to support the responsive mobile-first layout. Skins are no longer single-file CSS overrides — they are now structured theme packages with separate mobile and desktop stylesheets, a theme manifest file, and optional JavaScript overrides.

Theme Package Structure in 5.0

/skins/
  /mytheme/
    theme.json          <-- theme manifest (name, version, author)
    desktop.css         <-- styles for viewport >= 768px
    mobile.css          <-- styles for viewport < 768px
    variables.css       <-- CSS custom properties (colours, fonts, spacing)
    overrides.js        <-- optional JS overrides (loaded after core APG JS)
    /images/
      logo.png
      favicon.ico

Migrating a 4.x Custom CSS File to 5.0

  1. Create the /skins/mytheme/ directory structure above
  2. Copy your 4.x custom CSS rules into desktop.css
  3. Test on a 320px viewport — rules that break layout need moving to mobile.css with appropriate media queries
  4. Extract colour variables to variables.css using CSS custom properties for easier future updates
  5. Create theme.json with your theme metadata
  6. Select the theme in Admin Panel → Display Settings → Theme

CSS Variables in APG vNext 5.0

/* variables.css — override APG vNext 5.0 defaults */
:root {
    --apg-primary:        #2c3e50;   /* navbar, links */
    --apg-secondary:      #e74c3c;   /* buttons, badges */
    --apg-text:           #2d3748;   /* body text */
    --apg-bg:             #f8f9fa;   /* page background */
    --apg-bg-alt:         #ffffff;   /* card/panel background */
    --apg-border:         #dee2e6;   /* borders */
    --apg-font-main:      'Segoe UI', sans-serif;
    --apg-font-mono:      'Consolas', monospace;
    --apg-radius:         4px;        /* border radius on cards */
}

Using CSS variables means you can make sweeping design changes (e.g., switching from a dark header to a light one) by editing a single variable rather than hunting for every instance of a hex colour across hundreds of CSS rules.

Post-Upgrade Rollback for 5.0

If the 5.0 upgrade fails partway through the deployment (not the SQL script — that runs in a transaction), the safest rollback is to restore the entire application directory from the pre-upgrade backup you took in Step 2. The database should not be affected since you haven't run the SQL upgrade script yet at that stage. However, if you did run the SQL script and the application deployment then failed, restore the database from the pre50.bak backup before reverting application files — the 4.5 codebase is not compatible with the 5.0 schema changes.

Related Resources

5.0 Migration Support