PPWC, 2026 Edition
Welcome to the 2026 edition of the Purdue Primary Web Cluster (PPWC). This is a technology refresh of the PPWC and, as such, there are items you should be aware of as a developer.
Important Changes
Newer software versions
The following table shows a quick rundown of the major software differences.
| Software | PPWC 2017 | PPWC 2026 |
|---|---|---|
| PHP | 5.4 | 8.3 |
| Perl | 5.16 | 5.32 |
| Python | 2.7 and 3.6 | 3.9*, 3.10, 3.11, 3.12, and 3.13 |
*If a Python version is not specified by the application or uWSGI configuration, 3.9 will be used.
Multi-Factor Authentication
The PPWC 2026 edition supports Purdue multi-factor authentication and single sign-on as part of standard HTTPD directory security via Shibboleth. No developer configuration or application support is required. Any site using standard directory security today will automatically begin using Purdue multi-factor authentication when they migrate. Any site using an application-based method, such as phpCAS, will want to migrate to Shibboleth after migrating to the new PPWC. Contact Web Services for details once you’re ready.
PHP Opcode Caching
Because it runs PHP 8, the PPWC 2026 edition supports and uses PHP opcode caching (a.k.a. the Zend OpCache) with JIT compiling and tracing support enabled. Beyond the speedup from simply moving from PHP 5 to the more efficient PHP 8, opcode caching stores pre-compiled PHP scripts in memory, allowing frequently requested pages and background scripts to produce output much faster.
While the OpCache configuration in place is set for maximum compatibility and security, there is a chance that some PHP scripts won’t benefit from caching, or may even run slower because of it. If you discover noticeable performance issues from very large PHP scripts, contact Web Services to have them omitted from caching.
Hostname changes
With the new 2026 edition of the PPWC, all of the hostnames change and you’ll need to update your configurations for SSH/SFTP, Dreamweaver, Contribute, Cascade, etc. Additionally, if you have active code that tries to determine the name of the host on which it is running (perhaps to try to determine which database server to contact), you’ll need to update those names. However, we recommend that you instead change your code to use the TIER environment variable we provide. For SSH/SFTP, Dreamweaver, Contribute, Cascade, etc., these are the names:
| Tier | PPWC 2017 (Current) | PPWC 2026 |
|---|---|---|
| dev | ldvwebapa02.www.purdue.edu | ldvwebapa03.www.purdue.edu |
For reference to what host you are on:
| Tier | PPWC 2017 (Current) | PPWC 2026 |
|---|---|---|
| dev | ldvwebapa02.itap.purdue.edu | ldvwebapa03.it.purdue.edu |
| qa | lqvwebapa02.itap.purdue..edu | lqvwebapa03.it.purdue.edu |
| prod | lpvwebapa02a.itap.purdue.edu lpvwebapa02b.itap.purdue.edu lpvwebapa02c.itap.purdue.edu lpvwebapa02d.itap.purdue.edu |
lpvwebapa03a.it.purdue.edu lpvwebapa03b.it.purdue.edu lpvwebapa03c.it.purdue.edu lpvwebapa03d.it.purdue.edu |
If you have other questions about the host names (including needing IP addresses or such for external firewalls not managed by Purdue IT), please contact us.
What Should I Do?
The most important thing is to migrate your site before Summer of 2027. The PPWC 2017 is nearing the end of support and needs to be decommissioned after the summer of 2027, so all sites must be migrated by then. Any sites not migrated at that point will be retired alongside the PPWC 2017 environment.
Web Services will not migrate sites unless requested in an effort to clean up old, unmaintained sites that are no longer needed. Regular reminders will be sent to developers.
Requesting Migration
To migrate your site to the PPWC 2026 environment, please contact Web Services to open a ticket. In this email, please include:
- Current Site URL: The Production URL of the site you’d like to migrate. Please only request one site migration at a time. All sub-sites will migrate at the same time. The site will be given a temporary URL to use during migration, and the real URL will be moved to the PPWC 2026 once you’ve completed migration.
- Ownership Changes: Please note any changes to site ownership.
- Developer Access Changes: Please note any changes to developer access.
- Important Site Details: Please note if the site uses a Cascade service account, Perl, Python, a mapped file share, or an ODBC database connection. If you aren’t sure, we’ll try to help.
You can see your site’s current owners and developers by looking it up in our Service Reports tool. What migration looks like for each site will depend on the technology it uses.
Cascade Site Migration Procedure
Cascade-based sites are usually very straightforward to migrate. To migrate your Cascade site:
- Make the migration request, as described above.
- Web Services will contact you with the updated transport configuration and temporary testing URLs.
- Update your Cascade transport to use the new configuration. All updates made to your site from this point forward will publish to the PPWC 2026 instead of the PPWC 2017.
- Re-publish your entire site.
- Test your site at the provided temporary Development testing URL.
- Deploy to your temporary QA testing URL and test there.
- Deploy to your temporary Prod testing URL and test there.
- Inform Web Services that you’re ready to complete migration.
- Web Services will move your site’s real URL to the PPWC 2026. Migration is complete.
If your Cascade site uses PHP for output, you will want to test thoroughly during steps 5, 6, and 7. Basic PHP output from Cascade should be perfectly compatible with PHP 8, but if your site uses custom-written components, there is a chance you will need to make some changes to them, or request that the module developer make updates. See PHP application considerations below for full details.
Standard Site Migration Procedure
Most other sites will migrate using a procedure along these lines:
- Make the migration request, as described above.
- Web Services will contact you with the updated SFTP configuration and temporary testing URLs.
- Use your SFTP client with the current settings for the PPWC 2017 to download a full copy of your site. If you already have a local copy or use a version control system like git to manage your site, you can skip this step.
- Update your SSH or SFTP client settings to use the new configuration.
- Upload your site to the new Development server. If you use a version control system, you can instead clone your current site release into your site’s directory on the new Development server.
- Test your site at the provided temporary Development testing URL.
- Deploy to your temporary QA testing URL and test there.
- Deploy to your temporary Prod testing URL and test there.
- Inform Web Services that you’re ready to complete migration.
- Web Services will move your site’s real URL to the PPWC 2026. Migration is complete.
If your site uses server-side scripting via PHP, Python, or Perl, there may be some additional considerations during migration. See below.
PHP Application Considerations
Due to the large number of changes and deprecations between PHP 5.4 and 8.3, expect most PHP applications to require some level of re-development during migration. This will occur during step 6 shown above. The following documentation discusses important changes between PHP versions that you’ll want to read through and keep in mind as you update your code:
- https://www.php.net/manual/en/migration55.php
- https://www.php.net/manual/en/migration56.php
- https://www.php.net/manual/en/migration70.php
- https://www.php.net/manual/en/migration71.php
- https://www.php.net/manual/en/migration72.php
- https://www.php.net/manual/en/migration73.php
- https://www.php.net/manual/en/migration74.php
- https://www.php.net/manual/en/migration80.php
- https://www.php.net/manual/en/migration81.php
- https://www.php.net/manual/en/migration82.php
- https://www.php.net/manual/en/migration83.php
A major change with PHP 8.x is that it will no longer tolerate most coding mistakes. While PHP 7.x would guess at what a developer meant and try to do something intelligent, PHP 8.x will give up and crash instead. During testing, you’ll want to watch PHP’s error log, which is now a single log for all sites using the same PHP-FPM instance.
During Development testing, you can even watch the log live in your shell using SSH. Simply run tail -f /var/log/php-fpm/www-error.log while connected to the Development server over SSH to watch the log. That will show the errors for every site, so you may want to use something like tail -f /var/log/php-fpm/www-error.log | grep "my/site/directory", where “my/site/directory” is a part of your site’s path that uniquely identifies it.
Finally, the modules available to PHP applications on this environment have some changes:
- No changes: <all core modules>, pear, bcmath, gd, imagick, mbstring, soap, ssh2, xml, zip, and composer. JSON support is now included as a core module.
- MySQL Support Change: PHP now uses mysqlnd instead of mysql or mysqli
- (New) PostgreSQL Support: PHP now supports PostgreSQL via pgsql
- Deprecated modules (no longer available): imap, mcrypt, http1, and xmlrpc
- Deprecated tools (no longer available): PHP Unit and PHP Code Sniffer
Python Application Considerations
Python applications require a few extra steps to set up during migration, and may require you to answer a few extra questions, namely the version of Python you want to use, but otherwise they will follow the standard procedure outlined above and should migrate without much fuss (unless your application uses Python 2.7, which is no longer available).
During migration, you will want to upgrade all libraries you’re using to the latest version compatible with the version of Python you’re migrating to. You’ll also want to note how to call each available version of Python when you’re logged into Development on the command line:
- “python” will now get you Python 3.9 instead of Python 2.7
- “python3” will now get you Python 3.9 instead of Python 3.6
- To run a different version of Python, request it specifically:
- python3.9
- python3.11
- python3.12
- python3.13
As mentioned earlier, Python 3.13 does not yet feature native database access libraries, so would need to access databases using ODBC. Using Python 3.9, 3.11, or 3.12 is recommended instead.
Perl Application Considerations
Perl applications shouldn’t require much additional effort to migrate, if any at all. The only important consideration is to mention that your site uses Perl when requesting migration so we set it up correctly on the new environment.
As always, please feel free to contact us if you have any questions or concerns.