Member Avatar for neoanomally

Lay of the Land

I have been tasked with rewriting a website, (I'm new to the ways of PHP). This website is a way for users to transfer files, usually between 10 MB - 1 GB using HTTPS; which includes a coupling to a broad single-sign on service. Half the files are in PHP the other half use mod_perl and CGI (PERL was the primary part of the site during its inception in 99). The site has been untouched since 2008, the original developer left. Towards the end he did primarily everything in PHP but kept building on the perl since he didn't have a chance to rewrite it all before he left. I have little documentation that he left, but one of the few pieces I had was a very general/braod to-do list. And it looked like he was transferring most the PERL-cgi stuff to strictly PHP... Also there is no database with this program, it usees an XML log file. Any files on the server over X days are deleted.

Problem

My problem is there are over 100 perl files. Everything I have done in the past has been ground up or just added functionality to a site. The minor things that I have changed thus far have all been javascript and php. But the meat of the code is in perl and I'm not sure if I should read through and catalogue the code which would include learning perl... Or should I write the everything in PHP. There are many different directions I could go. I am competent in PHP, python, c++, java, but not PERL x.x

Questions
1. IS there anything that PHP can't do that the perl stuff is doing?
2. How would you suggest I approach this problem from a methodology standpoint. -What approaches can I take to tackle this problem?
3. Any reference material that I should use?

  • 2 Contributors
  • 2 Replies
  • 216 Views
  • 3 Hours Discussion Span
  • Latest Post Latest Post by neoanomally

Dani AI

Generated

This project is a classic legacy/modern mix: large HTTPS file transfers, an SSO coupling, an XML-based logging/retention system, and ~100 Perl CGI/mod_perl scripts alongside newer PHP code. A big-bang rewrite is high risk; an incremental, test-driven migration reduces downtime and regression risk.

Begin with a short, verifiable inventory: map every public URL to the script that serves it, list which scripts handle uploads, where the SSO handshake happens, the cron/delete jobs that prune files, and any XML-log readers. Add lightweight request logging and synthetic tests so each behavior can be reproduced on a staging server with production-sized files. Run language-specific profilers and simple load tests to find real hotspots rather than guessing where the slow paths are.

Use an incremental migration strategy (the "strangler" approach). Options, from lowest to highest risk:

  • Keep stable Perl in production and only harden or optimize bottlenecks.
  • Wrap key Perl endpoints behind a small HTTP/JSON adapter, then reimplement endpoints in PHP one by one and switch traffic gradually.
  • Full rewrite only after automated tests cover auth, upload/download, and deletion logic.

Practical notes that matter for file-transfer sites: always stream files instead of buffering them in memory; confirm PHP/Server limits (upload_max_filesize, post_max_size, max_execution_time) if migrating upload code; preserve SSO token/session semantics when splitting endpoints; harden file-handling (sanitize filenames, enforce ACLs, scan or quarantine uploads, guard against path traversal). Replace the brittle XML log file with a simple transactional metadata store (SQLite or a small RDBMS or append-only object metadata), and make the deletion job idempotent and atomic.

As pointed out, Perl-to-PHP mapping references help speed porting; as noted, reading core Perl scripts to understand constraints is worth the upfront time. Final checklist: inventory, add tests/instrumentation, identify real bottlenecks, pick a strangler-based migration plan, and validate on staging with production-sized transfers before any cutover.

Recommended Answers

All 2 Replies

Member Avatar for neoanomally

Well I understand high level stuff of what some of the stuff does. I think part of the problem with the site isn't the fact that the perl isn't powerful, it's more that I feel that the person didn't build the site to scale so there are a few performance bottlenecks. I wasn't sure if I should modify the perl and overall structure on how things are stored and retrieved. Redo it in PHP etc...

Part of it is I'm not sure how to approach and tackle this site since I'm used to doing everything ground up and designing first instead of taking something that's already made..

Thanks fort he input so far! Looks like I"ll be learning perl, I'll probably just try to figure out how to redesign the site so that it can handle the number of users we get. Thanks for the tutorial.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.