Ugh. Sorry. That’s what I get for not switching my dev branch while confirming things. It looks like we renamed that option in InterWorx 7. It was previously named sync-vhosts.
~iworx/bin/httpd.pex --sync-vhosts --domain domain.tld
or
~iworx/bin/httpd.pex --sync-vhosts-all
Sorry about that!
Hello–
Your custom section for redirecting to https is probably best placed in the domain’s /home/unixuser/var/domain.tld/apache folder. Any file in that folder (that ends in .conf) will get loaded at the end of the vhost. This give you a lot of flexibility without requiring you to directly edit the vhost itself. I’d simply add a file to each domain (a name like https-redirect.conf makes sense) with the contents of that file in it.
It’s important to know that while vhosts were persistent in previous versions of InterWorx, they will NOT be persistent in InterWorx 7, which is the reason this check is being done. If you make a change directly to the vhost for the domain, it is likely that it will get overwritten in the future. This is the result of the new vhost templating system. Having said that, the new templating system still allows you to make custom changes but you must do so in a template file and not directly in the vhost itself. This is generally not necessary as the above mentioned var folder should work for most common vhost edits. More information about this can be found on InterWorx 7 servers at /home/interworx/etc/templates/README.md.
I don’t believe there is any limitation for the 1 domain free IW. It’s probably best to open a ticket with us so we can get more information. I’m sure we can get you where you want to go.
Thank you,
Brandon
New flag makes more sense 
I ran this command on a site and still shows errors when I rerun the preflight.
My host has a ticket open with you guys now, so I’ll see what they say there.
Hi
I have also just run the command and the preflight test shows same issue
I have opened a support ticket but there is absolutely no rush on my ticket. It is only a DNS server using the free 1 domain version of IW and has been running years
The https .conf sound good but I suspect we may be like others, where there are a mixture of http and https websites and IW will be set to show the first https website if no SSL installed on a website but referenced by https:// and also this may stop Lets Encrypt as it detects it is not the same domain
I could be wrong though, so apologies in advance
Many thanks
John
Sorry I should have waited until your post sunk in, and I was thinking you meant in /etc/httpd/area so yes that sounds lovely thank you
Many thanks
John
I just ran the upgrade tool, and it is slick! You did a great job on it. No errors with the upgrade tool, and nothing in the upgrade log.
The only issue I’ve found so far is that in Siteworx > Accounts, if I set the ordering for ascending on username, it doesn’t save the setting if I leave the page, though that may be intentional.
Thank you for giving us the upgrade tool!
P.S. Toggle dark mode is awesome!
For anyone else following at home, it looks like --sync-vhosts isn’t “rough” enough with the changes being found in these vhosts. The “delete and rewrite it completely” option is a flag called --generate-conf which rewrites the conf from scratch.
~iworx/bin/httpd.pex --generate-conf --domain domain.tld
I’m working my way through your server, @Justec, and updating any ones that don’t have other modifications to the vhost. I’ll update the ticket your host sent us with more information. If you don’t care about the modifications that are found in the others, you can use that command to overwrite them, but some of the modifications look important, so please check the remaining ones carefully.
@d2d4j, I plan on getting to you next. It’s been a long day here at InterWorx, but I’ll make sure you have something before the end of my shift.
@justec - Just sent some details to your host about a few more “failures” that actually are customized vhosts. If you have any questions about it, feel free to have them reach out again. The --generate-conf command took care of roughly 80% of the ones that previously were marked as “customized”.
@d2d4j You’re all sorted.
Thanks everyone!
Hi
@iworx-brandon kudos to you and IW
Thank you and appreciate your time. Honestly there was no rush on the one I opened a ticket on but you went above and beyond
Many thanks
John
Thanks Brandon, that’s great news! Sounds like most of them were just old IW template, so just need to look at the handful of them that actually have customizations.
I wonder if it would be feasible to update the upgrade tool to detect official, but old / outdated, InterWorx vhost templates and force the refresh, leaving just the truly customized ones alone. Seems difficult, but maybe possible!
I went through and updated the remaining ones, the only one I had an issue with was a secondary domain. When I ran the forced vhost rewrite it did it, but only for HTTP, not HTTPS. I’m guessing this is just an issue with VHOST rewrite in this specific secondary domain situation, since you only set SSL for the main siteworx account and it applies to all the secondary domains, no way to set an SSL for each secondary. I think I can just look at another one I rewrote and change the paths and domain names for SSL portion and that should fix it.
We are going to see if we can get another hotfix out that should correct the issue with these older vhosts. It actually looks like we attempted to correct these missing vhosts sections with an upgrade step back in 2017. Based on the testing we’ve done today, it appears that that upgrade step could return a “successful” message even when it wasn’t actually successful. I suspect that is the main reason these vhosts are out of line. None of our testing servers contained accounts from pre-2017, so that’s a new find for us.
The way that SSL is setup in your vhost is non-typical and should count as a customization. Secondary domains can (and should) have their own SSL separate from the primary domain’s. Go to the SSL option under “Hosting Features” in the SiteWorx account and then in the top right corner there should be a button called “Change Domain”, change that to the secondary domain and then you can manage that domain’s SSL. It’s probably easiest to just create a Let’s Encrypt cert for that secondary domain with the Let’s Encrypt plugin. This should make the vhost customization completely unnecessary.
Let me know if you have any additional questions.
Thank you,
Just some info, not sure how relevant it is, but looking at the sites with errors and creation dates this is what I found. Last site showing errors for me was created July 3 2019 and site created in January of 2020 was ok.
Wow, I never realized that was an option! That’s great, being able to pick secondary domains as the active one in SiteWorx. So this really basically behaves as if you setup completely different SiteWorx accounts, but all under one.
I will work with the person that manages that particular site and see about getting a SSL setup for it and then run the vhost script again! Thanks again Brandon!
EDIT: that did the trick, I’m all green now! Thanks again…again Brandon.
Just a heads up, that “Change Domain” feature is a bit more intuitive in InterWorx 7. When you go to “manage domains” the shield icon next to each domain allows you to manage the SSL for that domain. A lot less context switching and going back and forth between things. Screenshot below:
I’ve noticed a couple of things so far while testing the upgrade.
So you did the upgrade and those are the only two issues you’ve run into? That’s awesome. I’m planning to do this upgrade in about a week.
Yeah, this is much more intuitive! Excited to upgrade soon.
Yes, so far, just those two issues, and I’ve been working the UI hard.
I’ve deleted hosting accounts, added new secondary domains, added a pointer domain, created email accounts, generated SSL certs, used the File Manager for uploads and downloads, created SPF, DKIM, and DMARC DNS records, and those two issues are all I’ve found.
Unfortunately, I was not able to recreate a change of “Start on boot-up” when upgrading the server. Screenshots included:
Did the .htm files contain php code or were they just html? There is some php-fpm stuff the needs to occur when loading php from .htm files.
We just released a hotfix that should take care of these missing sections from old vhosts. Thanks for reporting the issues you were having so we could correct it.
Thanks again!
Brandon