"New" version still running the .pl script and doesn't recognize env variables for the "new" style

[ember1205]

Ok... What am I missing here?

I have been running this specific container for a couple of years without issue until early this year when the zap2it web site went away. I was able to work my way around that by locating another container (from another author) that had fixed that problem.

A handful of weeks later and it was broken again. Somehow, I made my way back here and was able to get this working again. I had an odd issue with my local setup a couple of days ago and decided to try and restart the container. It ended up pulling the new version, and I found myself pretty much right back to where I was five months ago... It was giving me status 400 errors.

I tried all sorts of various combinations of command line options and env variables that are outlined on the main page for this release, and absolutely nothing made any bit of difference. I was finally able to get it working again ONLY be executing a command from the Docker host to launch an SH session in the container and edit the /opt/zap2xml.pl script and change the "AID" value from the version that hasn't worked in MONTHS ("lat" - this ID stopped working sometime in July, I believe) to "chi" and it immediately began to work again. Other known working values that I can recall off the top of my head are cha and orbebb.

What am I missing? Why did deploying a brand new instance of this container refuse to accept any of the settings or variables that are outlined? And why is the AfilliateID parameter a) so woefully out of date and b) not available for configuration via command line or environment variable?

[Swamp-up]

Are you using the perl script (.pl) or the other .ts script. (Sorry I forget what that is written in)?

Are you sure you are pulling from jef/zap2xml ?
There are a few older scripts running from different githubs.

[ember1205]

Given that I had to edit the zap2it.pl script to get it working, I would have to say it's running the perl script.

As I mentioned, I've been running this container for a couple of years and when it broke earlier this year, I was able to get it running again by "duplicating" the container, deploying with a fresh pull of the image (which removed the old container), and then shelling into the container and editing the perl script. This is what I had to do -again- this week when I accidentally refreshed the image and it downloaded a (still broken) container (outdated perl script). The only thing I can guess is that launching the container with the "entrypoint.sh" script, which seems to be what's launching the perl script, it's continuing to use the Perl script method.

I have found no information anywhere that tells me how to modify an existing container to "switch" operating methods - everything documented seems to be only for those that have never deployed the container before with the expectation of doing it "the new way" even though "the old way" is still there. I'm hesitant to do a full switch to the new style using a completely fresh install because everything for containers is always documented for Docker Compose and I use Portainer (which doesn't support the compose construct directly and I'm not well versed enough with containers to easily re-write one to the other so it works). In other words, the level of effort that often have to go through to get a container working in the first place makes me not want to start fresh. :)

And, yes... I'm pulling THIS container using the "latest" option to get the latest stable build. Here's the reference link for my container: ghcr.io/jef/zap2xml:latest

[Swamp-up]

Sorry. Missed the reference to the perl script.

Here is where I get confused as well.
In both the historical perl script and the new script here in github, they both reference to pull from ghcr.io/jef/zap2xml:latest in the docker compose file.
Which is the same for both the historical and the newer script.

So I wonder if that is what is causing your problem.

I am using xtreve that also has the zap2xml perl script. I ended up pulling just the newer historical zap2xml.pl file into this container so I can still use it.

[ember1205]

Dunno... The docs leave a lot to be desired, and I'm kind of surprised that the author has stated he's maintaining the older PL file but the format it's in actually broke over five months ago.

I have it up and running at the moment, and have made some detailed notes on my side about what needs to get change, to what, and how I did it so that I can do again down the road if I need to. But, I'm going to look for other options for collecting XML data for my setup as well.