EidolonHost

Looks like I'm in the clear after I removed the database entries... I'll give it a while longer, see if it encounters further issues before I call it good but your suggestion did the trick.

Oh, so it is. Whoops. Updated, now we match in versions. The spinning icon is still there in the Automation Tasks section... so it's obviously not fixed...

Nope, not the loaders. I even used your improved ioncube installer because it's actually better than my own installer.

Nope... been running on 5.6. That's the weird part. [eidolon@eidolonhost ~]$ php -v PHP 5.6.24 (cli) (built: Jul 21 2016 07:33:38) Copyright (c) 1997-2016 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v5.1.2, Copyright (c) 2002-2016, by ionCube Ltd. [eidolon@eidolonhost ~]$

So... today, I suddenly got an e-mail from the server, noting that a segmentation fault had occurred from the cron it was running. /bin/sh: line 1: 10692 Segmentation fault /usr/bin/php /chroot/home/eidolon/eidolonhost.com/html/billing/index.php cron > /dev/null 2>&1 I check what was wrong, it appears that the server is unable to download tickets. I check account details and update accordingly where necessary. Log into them after updating details, all good. Still hanging. WTF. Is Google having e-mail issues today? Checking Google's Dashboard reveals no issues out of the ordinary... I even checked to see if the port for the connection was open in the firewall and it was. Up until today, it was running just fine. Suddenly now I am watching that spinning circle taunting me even after I rebooted the server to clear any weird funkiness out, just in case.

This is a great idea that I'd love to see implemented. Anything to further security is good in my opinion, as long as we try to make it as painless as possible.

Works for me here still, via the web upgrader. Edit: Correction, the client portal seems to be white-paging. I'll enable error reporting here shortly to see what's going on. While the upgrade DID complete properly, the client portal seems to have blown up. Edit2: False alarm. I blew away the client area portal templates... that'll do ya for fucking it up, Keiro... -facepalms-

I was able to successfully upgrade from a test 3.6.2 instance to a 4.0.0b1 instance. I had forgotten to complete the upgrade via admin/upgrade but even having not done that, it worked pretty nicely. Then I did the admin/upgrade when I checked out another thread that reminded me of its existence. Things seem to be A-OK here. But I'll try this with a copy of current-production data.

I'd have to agree with the others... it's best to have a billing-system dial for how many to send at any given time. I would not assume that the mail server will spool it for you and send it out in batches. I would assume that by default you should have the option to control how often it sends e-mail and how quickly it should send that e-mail. Complying with the CAN-SPAM act in the US and other likewise legislation in other countries would be difficult if you assume that any Blesta user wouldn't mind having their billing server be blacklisted for sending out too much... even if it is legit.

... I completely forgot to do the upgrade. Fortunately, it didn't do anything damaging since I hadn't performed the upgrade... But, doing the upgrade via web went through nicely. It did redirect to the admin dashboard with a completed successfully message. php 5.6 here, default install on a development server. This was from 3.6.2 to 4.0.0 beta 1. Wouldn't be surprised if you had a module or something similar causing a white page but... this is basically a very clean install, so it seems to have worked for me in that aspect. Edit: The upgrade took about 2-3 seconds or so before it completed.

That was to @timnboys, sorry.

If you'd like help in ensuring the module works okay, I'd be happy to help ensure the module works to your expectations.

Hmm. Interesting product along with a possible on-premises solution. Interesting. I'd be happy to help with beta-testing this module on a development system. I'll sign up later at some point today and let you know when I do.

New security measure that helps browsers load stuff ONLY whitelisted by your content-security policy. The link I included in my previous post should help with understanding this in-depth. You can see this for yourself with https://securityheaders.io/?q=https://eidolonhost.com/ It's still a bit of a work in progress, fine-tuning my CSP policy for the server.

Yep. Equally very simple... and I just realized that's why my Blesta install looked so fucked with Content-Security-Policy enabled... I forgot to whitelist the CDN... Well... that will be fixed later. But it's likely something to watch out for as people start implementing Content-Security-Policy. Something to note in the docs, maybe?

Isn't updating FontAwesome as simple as downloading the relevant FontAwesome pack if you don't want to go the cdn route?

Had a play with the beta just recently. Looks pretty damn good. I'll install a development copy on the testing server I have, which is running php 5.6 although there is the possibility of also running php7... but I'll have to check into that. I'll report back any issues I find but I must note I like the new look. Seems a hell of a lot cleaner to me, truth be told. I was playing with this on Licensedemo.com so I didn't notice any initial issues, but best to install it on our own server and take a look under the hood as well.

That is very good to know. I've noticed you have done other modules for the competitor and have released open-source versions as well. I like this, as it provides the buyer with a lot of flexibility. Still, I hope you do well here.

Nice, welcome back to the land of Blesta. I was sad to see you guys go when you signed your exclusivity agreement. Hopefully now that you've returned, we'll be able to do more business here. I suspect that most people will come to you and insist on having a copy of the source in the event you are forced to do what you did last time, from this point on. I know I would, if I considered hiring ModulesGarden for my module development needs.

Oh man. AnthonyL, you make such good points here that I can't help but to want to reiterate your points, especially with your last point, Blesta's origin being that of a host's billing system. I've been here since I believe 3.x, as I missed the boat on 2.x but I can see Blesta faltering here and there with the uncertainty. Plus, with so few developers, I've had a lot more difficult time in getting a developer to work with me as a small-time host. The direct competitor to Blesta has loads upon loads upon loads of developers that it's stupid easy to get someone to develop for you on that platform. And cheaper, too. Which really sucks because Blesta is a great platform to build on as long as you're aware of its limitations and plan on building off the core.

Paul, Thanks again for checking my system out and spotting the issue. Turns out it was because I had reminder notices set to be sent out before the due date... which explains a lot.

Nice, thanks. There were a few that had CC cards stored on our system. Ouch! All good to go from here. Thanks for the quick help on this one.

No customizations other than the theme. Customer paid invoice, no problems there... but I realized I derped on the timing of the next invoice deliveries. I'll open a ticket and provide deets because from what I can see, it all should be good, but it obviously is not. As to your suggestion regarding backing up everything... no problem. I'll just back up the theme and the blesta.php, or rather, the crucial bit that we need for encryption. Wouldn't want to lose it and such... >_> I'll report back if doing this resolves the issue. Although... I will note, I updated to 3.6.1 by doing exactly what you just suggested here, so... I don't know. Also, a bit off-topic but: Is there a query of some sort that I can use to discover who has a credit/debit card on file and purge said data? I want to force our customers over to Stripe and/or Paypal as credit/debit card storage locations because they've the ability to securely store credit card data and we want to be absolutely 100% sure that neither Paypal nor Stripe're storing card details locally. (though I know Stripe won't store card deets locally since I'd already enabled the option to store card deets off-site...) ... and well, let's just say, I'd rather not be the one holding the bag for a credit/debit breach. >_>

Both. I am not certain as to whether or not the system is sending it like that, to your last question.

I've resaved those forms many times in the past... and nothing's changed. O_o; The late/reminder notices go out the same day every invoice is created, yes. EVERY invoice, for all clients. Edit: I've a client that should get the reminder notice three days after tomorrow. I'll report back if it's fixed. Edit2: I'd be happy to provide access to the server in question to observe the behavior?