mobbdeep

February 22, 2020

12 hours ago, Tyson said:

Did you update your mail settings in Blesta to connect using the details for the new host? Same with the cron job on the web server?

I always had mail settings in Blesta set to PHP as the delivery method because I use Zoho to host my emails and CloudFlare to manage my DNS. As far as the cron job, yes, I updated it as well in crontab -e as I'm running a CentOS 7 VPS. I can go to a client profile, choose "Email Client" and send an outgoing email and it works fine. Same with responding to that email and opening it in Zoho. However, when I use the Mass Mailer plugin, I get the connection refused and same with the cron job when I try running it manually. Never had that issue before switching.

Here's my crontab -e

Blesta email settings

Cron Logs in Blesta

CloudFlare DNS Setup

Sorry for masking the domains. I can easily PM you as requested if needed.

February 21, 2020

9 hours ago, Jono said:

What version of Blesta and PHP are you on?

Just upgraded to the latest version of Blesta and I just upgraded to PHP 7.2. Everything seems to be okay except for what I mentioned in the below reply.

8 hours ago, Tyson said:

Enable error reporting in Blesta and then try to duplicate the white page. That page should show the errors that are occurring. Be sure to disable error reporting after you are done testing.

Since you moved hosts, the new host probably does not meet the minimum requirements to run Blesta. You will need to have your host install whatever extensions are missing once you determine what those are.

I was missing some PHP extensions. I installed the ones that were missing. Also, I did notice when I go to manually run the cron job in the Blesta settings, it says "mydomain.com refused to connect" and same for when I use the mass mailer plugin to send an email to all my clients.

February 20, 2020

Hello,

Two things have been brought to my attention recently. First, I just switched to a new hosting provider for just my website to be ran on separate from my cPanel/WHM server. Since I made that change, I noticed emails are going unsent in logs and when I try to email a client from their client profile, I go to hit send and it redirects to a blank white page. I hit refresh and it just refreshes me back to composing the email page. I noticed this happening when replying to tickets as well. Before I switched hosts, I had no issues there but my clients were telling me that once they go to checkout in the cart after choosing their plan, it redirects to a white page as well. I am under the impression this is a PHP issue but I can't seem to find the issue.

Thanks!

May 24, 2019

11 hours ago, Tyson said:
The package's welcome email contains the "service" object, and the package options are available in a list of "service.options". You would have to loop over the "service.options" and then evaluate the specific option to display the option name and value (e.g. "Admin Password: abc123").

For example:
{% for option in service.options %}
	{% if option.option_name == 'admin_name'}{option.option_label}: {option.value}{% endif %}
	{% if option.option_name == 'admin_pass'}{option.option_label}: {option.value}{% endif %}
{% endfor %}
The above would look over all service options, and display admin name and password if those are options on the service:
Admin Name: myname
Admin Password: mypassword

Where would I implement the service.options?

May 23, 2019

12 hours ago, Tyson said:

In your screenshot for the package option "Script", I notice that the "Name" is capitalized as "Script" rather than "script" as mentioned in the documentation. I believe that is case-sensitive, so it may be why WP does not get installed. I would update that and retest first.

The package has 1 and 3 month terms, but the package options are only setup for 1 month, so it would only be installed if the 1 month package was ordered, not the 3 month package.

Thank you, I will go ahead and update those pieces of information. I have 2 additional questions..

1. Since I am doing 1 month and 3 month terms, do I still setup the package option price at 0.00 like I did for 1 month or should I specify the price for 1 months and 3 months? Also, how do I specify how many domains they can host per WP package? Eg. I see hosting providers offering a package with 1 domain allowed and then another package with 2 domains allowed.

2. When creating the Welcome Email in the package setup, what would the tags be for the Admin Username and Admin Password they created in the order form?

May 22, 2019

Hello,

I am attempting to setup the Blesta Softaculous Auto Installer feature and I'm having some trouble. I followed the video in this tutorial (https://www.blesta.com/tags/soft-auto-installer/) and I'm still not having luck with it automatically installing to the cPanel account once it's provisioned. I am using the same cPanel/WHM server for WordPress hosting as I am with my shared hosting services I currently offer. Below are screenshots of my configurations.

Package Group:

Package Option Group:

Package Option 1:

Package Option 2:

Package Option 3:

Package:

WHM Side (Package):

I have a Softaculous license as well and it's not auto installing Softaculous. Yes, the cPanel account gets created but just as normal shared hosting.

Regards,
Tyler

May 1, 2019

Does this work for Blesta 4.3.x?

February 27, 2019

On 2/25/2019 at 11:45 AM, Tyson said:

cPanel (and essentially all other systems) will not send notifications to services (like Blesta) regarding a password update made through their system.

If the cPanel password needs to be changed, then the user should:

Change it from within Blesta, or

Update it in Blesta after having changed it in cPanel

Would this ever be a possibility in the near future for Blesta? I know a lot of people are familiar with another billing software I won't mention and how when their password is updated via cPanel, it updates in their client area so that when they click the "Login" link, it works with their updated password and not give them failed logins because they didn't manually update the password themselves in Blesta?

Eg.

Change password in cPanel => New password automatically updated in Blesta
Change password in Blesta => New password automatically updated in cPanel
Change password in cPanel => Update it in Blesta after having changed it in cPanel

February 24, 2019

Hello,

I noticed that when a password is changed in cPanel via the password changing tool, it does not update the password in Blesta when using the "Login" link. I have been getting tickets regarding IP's being blocked in my firewall due to too many failed login attempts and they indicated they've been trying to login through the Blesta Client Area. I tested it on my personal non-administrator account and this happens.

Thanks,
Tyler

January 19, 2019

3 hours ago, Paul said:

If the issue occurs when suspended services, the next question is: What services are trying to be suspended, and what modules are they using? Since suspended services invoke the module, and the module can make an API call to remotely suspend a service, the module has a lot of control. If you are running any 3rd party or custom modules, then they could be suspect.

2 hours ago, Blesta Addons said:

wish module installed ?

I am running no 3rd party modules aside from the cPanel module.

3rd party plugins I am running:

Auto Cancel Unpaid Orders
Blesta Addons Widget
Client Notice
Delete Invoices
Resend Welcome Email

How can I see what services are trying to be suspended? If I can see that information, I may be able to figure out the issue. I believe it may be an account that no longer exists on my cPanel server that was manually terminated and Blesta is now trying to suspend that non-existing account via the module which is causing an error.

January 18, 2019

I switched away from a shared hosting provide onto my own Linux VPS for the sake of my own freedom and ability to 100% manage my entire web server. Anyway, I increased the max_allowed_packet and wait_timeout, and I am still getting the same result with the Suspend Services task.

Below are my php.ini settings:

Michael · January 18, 2019

It appears adding TLS support properly in my Apache config worked. To those who are using a setup like mine:

LAMP stack on CentOS 7
Used @Blesta.Store's tutorial (https://licensecart.com/brain/knowledgebase/398/How-to-install-Blesta-on-CentOS-without-a-panel.html)
Let's Encrypt SSL
Apache vHost (which you need anyway to use Let's Encrypt)

Your Apache config file needs to look like so:

<VirtualHost *:80>
        ServerAdmin email@yourdomain.com
        DocumentRoot "/var/www/html/yourdomain.com/"
        ServerName yourdomain.com
        ServerAlias www.yourdomain.com
        ErrorLog "/var/log/httpd/yourdomain.com-error_log"
        CustomLog "/var/log/httpd/yourdomain.com-access_log" combined

<Directory "/var/www/html/yourdomain.com/">
        DirectoryIndex index.html index.php
        Options Indexes MultiViews FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>

	Redirect permanent / httpd://yourdomain.com/
</VirtualHost>

<VirtualHost *:443>
        ServerAdmin email@yourdomain.com
        DocumentRoot "/var/www/html/yourdomain.com/"
        ServerName yourdomain.com
        ServerAlias www.yourdomain.com
        ErrorLog "/var/log/httpd/yourdomain.com-error_log"
        CustomLog "/var/log/httpd/yourdomain.com-access_log" combined

        <If "%{HTTP_HOST} == 'www.yourdomain.com'">
        Redirect permanent / https://yourdomain.com/
  </If>

<Directory "/var/www/html/yourdomain.com/">
        DirectoryIndex index.html index.php
        Options Indexes MultiViews FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>
	SSLEngine On
        SSLProtocol -ALL +TLSv1.1 +TLSv1.2
        SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/cert.dh.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/yourdomain.com/chain.pem
 </VirtualHost>

SSLProtocol -ALL +TLSv1.1 +TLSv1.2 is what's vital in this situation I was having.

January 17, 2019

21 minutes ago, Paul said:
I'm not familiar with firewall-cmd does that open up egress or ingress or both? Your server must be able to make an egress connection to us on 443.

Via SSH you can run:
GET https://account.blesta.com
To see if there is a response, should output HTML code for that page. If it does output the proper HTML code, then it's not the firewall and might be your PHP. PHP CURL is used to establish the connection.

If I..

curl -L https://account.blesta.com

It returns the HTML code for that page.

I sent you my php.ini via PM if you'd like to take a look. Again, I didn't make any changes to it that may interfere with the connection or license validation.

January 17, 2019

12 hours ago, Paul said:

Thanks for PM'ing me your license key. The license is in a state of re-issue, and has not been activated. Our license logs also show no requests for this license, so it's not just a matter of a failure to validate on our end, but no connection has been made to us. By all counts, your installation is not able to reach our license servers to validate the license.

Make sure port 443 egress is open at your firewall

Make sure you don't have any disabled_functions in your php.ini.. for example, if curl, curl_exec, are disabled in your php.ini, then Blesta will be unable to make any calls to any 3rd party API's, including for license validation.

The only other thing I can check on our end, is whether we are blocking your server's IP address.. but I will need that in order to check. We shouldn't be blocking you unless your server was sending malicious requests to us in the past.

I have PM'd you my VPS IP. I just got it the other day from Virmach so hopefully it doesn't come up blocked or anything.

Regarding port 443 egress being opened in my firewall, I double checked that and all is well. Also, nothing is set under disable_functions in my php.ini.

Just to confirm, opening port 443 egress would be:

firewall-cmd --zone=public --add-port=443/tcp --permanent

Correct?

January 16, 2019

5 hours ago, Paul said:

Probably your install is unable to validate the license. If you PM me the license key, I can check our logs. Another thing to note besides the things you mentioned, is that you should have moved Blesta by moving the database + files. The /config/blesta.php config file contains a critical System Key which must match the installed database. If you did something like a fresh install and overwrote your database then you would have permanently broken encryption, this included. This is mentioned in our Moving Blesta Guide.

5 hours ago, Paul said:

Also, just to add.. if you upload a fresh copy of Blesta to another directory on the server, and access in your browser, it will do a system requirement check. If you are failing on any of the common requirements then it will be obvious. You can delete the files after the check, no need to install. It won't check the firewall though.

I did the normal of what I normally do when moving hosts. I took a full site backup and a full database backup then uploaded my site to the new host and imported the database. The only difference of the database previously is the username and database name as when I was on cPanel, they were named cpaneluser_username apposed to now on a Linux VPS, it's just username. I didn't do a fresh install of Blesta or overwrote the database or anything. I just put the website on maintenance, took a backup of the database and website via cPanel, then uploaded both onto the Linux VPS running CentOS 7. I even followed @Blesta.Store's tutorial on his website's knowledgebase. I don't know if this makes a difference but I originally installed Blesta on a cPanel service which use the path ~/username/public_html/.. and now I am using ~/var/www/html/domain.com/.. but that shouldn't change anything since I didn't do a new install then try overwriting the new install with backed up files.

Also, I just did a dependency check with a new upload of Blesta in a separate directory and everything checks out good.

January 15, 2019

Hello,

I recently moved my entire service over to my own Linux VPS with a new IP, directory paths, etc. Previously, it was on a cPanel account but now it's on my own Linux VPS using Apache and the root directory path is /usr/var/html/blesta. The problem I am having is when I login to my AdminCP, it requires me to input a license key. At this point, I know to re-issue the license key at which I did through my reseller. However, upon entering the license key at website.com/admin/license, I get the following error:

They went as far as reissuing me a complete new license key but I am getting the same error regardless of how many times it gets reissued or given a new license key.

Additionally, I the following:

system.debug is set to false in my ~/config/blesta.php file
mbstring.func_overload is disabled in my php.ini
Latest version of CURL installed
SSL is enabled via php and Apache vhost
Port 443 is open in the firewall

Not sure what I am forgetting.

Thanks!

January 9, 2019

15 hours ago, Paul said:
The tasks that did not appear to complete in your original post did not run in your manual run, they must have already run for the day. Looking at your errors, this one stands out:

It's possible that MySQL is timing out. You could try increasing your wait_timeout value, typically in my.cnf to something like:

wait_timeout=3600

To check the current value, and to see if the change took affect you can run the following query:
SHOW VARIABLES LIKE '%wait_timeout%';
Are any tasks listed as not having completed under Settings > Company > Automation any longer? If so, which ones?

Unfortunately, my main website is on a cPanel account temporarily until I get things situated therefore I cannot change the wait_timeout in MySQL.

I did do additional logging and attached a .txt file containing logs for the cron job when it gets ran by cPanel.

In the logs, you will see "server.mydomain.com" which is referencing where my actual VPS is. Again, I am hosting just my website with Blesta on a separate cPanel service than where my clients are hosted. My clients are on a VPS I manage.

logs.txt

January 8, 2019

16 hours ago, Paul said:

When you switched hosting companies, how did you move Blesta? Did you follow the guide? If you don't copy all your files + database, and instead do a fresh install and overwrite your database you will permanently break Blesta.

Now that that is out of the way..

It sounds like the issue is with 2 tasks, Cancel Scheduled Services and Suspend Services? Is that right?

Did you check your logs? By default, the logs are at ../logs_blesta/ but the path is defined under Settings > System > General.

When a cron task is hung, it can take 6 hours for it to be cleared out automatically and re-attempted. If you ran the cron manually I would highly suggest doing the following:

Disable the cron job in cPanel

Wait at least 6 hours

Enable error reporting in /config/blesta.php (Change ErrorReporting from "0" to "-1")

Run the cron manually under Settings > System > Automation. Observe the output, and see if there are any errors.

Disable error reporting in /config/blesta.php

The same errors you might get by following this method should also exist in your logs, so you could check there instead.

Since the issue occurred after moving Blesta to another provider, it's possible there is some dependency that is not met. A simple check for that would be to upload a fresh copy of Blesta in a sub-directory and access in your browser so that Blesta will run a system requirement check. Don't install, just delete the files when done checking the results of the system requirement check.

Just updating..

I enabled the tasks I disabled, enabled error reporting, then ran the cron manually.

Attempting to run all tasks for SpdyHost.
Attempting to process service changes.
The process service changes task has completed.
Attempting to process renewing services.
The process renewing services task has completed.
Attempting plugin cron for order accept_paid_orders.
Finished plugin cron for order accept_paid_orders.
Attempting plugin cron for support_manager poll_tickets.
Finished plugin cron for support_manager poll_tickets.
Attempting plugin cron for mass_mailer export.
Finished plugin cron for mass_mailer export.
Attempting plugin cron for mass_mailer mass_mail.
Finished plugin cron for mass_mailer mass_mail.
All tasks have been completed.
Attempting to run all system tasks.
All system tasks have been completed.

Reviewing ../logs_blesta/ there are general-error, general-info, general-notice, and general-warning.

General-Error:

[2019-01-08 08:37:13] general.ERROR: Uncaught Exception Error: "Wrong parameters for BadMethodCallException([string $message [, long $code [, Throwable $previous = NULL]]])" at /home/domain/public_html/billing/core/Automation/TaskFactory.php line 59 {"exception":"[object] (Error(code: 0): Wrong parameters for BadMethodCallException([string $message [, long $code [, Throwable $previous = NULL]]]) at /home/domain/public_html/billing/core/Automation/TaskFactory.php:59)"} 
[2019-01-08 11:22:16] general.ERROR: Uncaught Exception Error: "Wrong parameters for BadMethodCallException([string $message [, long $code [, Throwable $previous = NULL]]])" at /home/domain/public_html/billing/core/Automation/TaskFactory.php line 59 {"exception":"[object] (Error(code: 0): Wrong parameters for BadMethodCallException([string $message [, long $code [, Throwable $previous = NULL]]]) at /home/domain/public_html/billing/core/Automation/TaskFactory.php:59)"}

General-Notice:

[2019-01-08 08:04:30] general.NOTICE: E_USER_DEPRECATED: The Swift_Transport_MailTransport class is deprecated since version 5.4.5 and will be removed in 6.0. Use the Sendmail or SMTP transport instead. {"code":16384,"message":"The Swift_Transport_MailTransport class is deprecated since version 5.4.5 and will be removed in 6.0. Use the Sendmail or SMTP transport instead.","file":"/home/domain/public_html/billing/vendors/swiftmailer/swiftmailer/lib/classes/Swift/Transport/MailTransport.php","line":45} 
[2019-01-08 08:05:05] general.NOTICE: E_USER_DEPRECATED: The Swift_Transport_MailTransport class is deprecated since version 5.4.5 and will be removed in 6.0. Use the Sendmail or SMTP transport instead. {"code":16384,"message":"The Swift_Transport_MailTransport class is deprecated since version 5.4.5 and will be removed in 6.0. Use the Sendmail or SMTP transport instead.","file":"/home/domain/public_html/billing/vendors/swiftmailer/swiftmailer/lib/classes/Swift/Transport/MailTransport.php","line":45} 
[2019-01-08 08:10:44] general.NOTICE: E_USER_DEPRECATED: The Swift_Transport_MailTransport class is deprecated since version 5.4.5 and will be removed in 6.0. Use the Sendmail or SMTP transport instead. {"code":16384,"message":"The Swift_Transport_MailTransport class is deprecated since version 5.4.5 and will be removed in 6.0. Use the Sendmail or SMTP transport instead.","file":"/home/domain/public_html/billing/vendors/swiftmailer/swiftmailer/lib/classes/Swift/Transport/MailTransport.php","line":45} 
[2019-01-08 08:14:06] general.NOTICE: E_USER_DEPRECATED: The Swift_Transport_MailTransport class is deprecated since version 5.4.5 and will be removed in 6.0. Use the Sendmail or SMTP transport instead. {"code":16384,"message":"The Swift_Transport_MailTransport class is deprecated since version 5.4.5 and will be removed in 6.0. Use the Sendmail or SMTP transport instead.","file":"/home/domain/public_html/billing/vendors/swiftmailer/swiftmailer/lib/classes/Swift/Transport/MailTransport.php","line":45} 
[2019-01-08 08:37:13] general.NOTICE: E_NOTICE: PDOStatement::execute(): send of 107 bytes failed with errno=32 Broken pipe {"code":8,"message":"PDOStatement::execute(): send of 107 bytes failed with errno=32 Broken pipe","file":"/home/domain/public_html/billing/vendors/minphp/db/src/PdoConnection.php","line":196} 
[2019-01-08 11:22:16] general.NOTICE: E_NOTICE: PDOStatement::execute(): send of 107 bytes failed with errno=32 Broken pipe {"code":8,"message":"PDOStatement::execute(): send of 107 bytes failed with errno=32 Broken pipe","file":"/home/domain/public_html/billing/vendors/minphp/db/src/PdoConnection.php","line":196}

General-Warning:

[2019-01-08 08:08:45] general.WARNING: E_WARNING: sprintf(): Too few arguments {"code":2,"message":"sprintf(): Too few arguments","file":"/home/domain/public_html/billing/vendors/minphp/language/src/Language.php","line":125} 
[2019-01-08 08:08:52] general.WARNING: E_WARNING: sprintf(): Too few arguments {"code":2,"message":"sprintf(): Too few arguments","file":"/home/domain/public_html/billing/vendors/minphp/language/src/Language.php","line":125}

I did notice earlier there was an issue with a clients account where the domain was actually terminated from my cPanel server back in June but the service was still appearing as suspended in his Blesta account area. I went ahead and set the domain as cancelled without using the cPanel module so I'm not sure if maybe that was causing a problem. But above is all of the information I have gathered earlier.

Canceled Scheduled Services, Suspend Services, Unsuspend Services are the tasks I am looking into.

January 8, 2019

9 hours ago, Paul said:

When you switched hosting companies, how did you move Blesta? Did you follow the guide? If you don't copy all your files + database, and instead do a fresh install and overwrite your database you will permanently break Blesta.

Now that that is out of the way..

It sounds like the issue is with 2 tasks, Cancel Scheduled Services and Suspend Services? Is that right?

Did you check your logs? By default, the logs are at ../logs_blesta/ but the path is defined under Settings > System > General.

When a cron task is hung, it can take 6 hours for it to be cleared out automatically and re-attempted. If you ran the cron manually I would highly suggest doing the following:

Disable the cron job in cPanel

Wait at least 6 hours

Enable error reporting in /config/blesta.php (Change ErrorReporting from "0" to "-1")

Run the cron manually under Settings > System > Automation. Observe the output, and see if there are any errors.

Disable error reporting in /config/blesta.php

The same errors you might get by following this method should also exist in your logs, so you could check there instead.

Since the issue occurred after moving Blesta to another provider, it's possible there is some dependency that is not met. A simple check for that would be to upload a fresh copy of Blesta in a sub-directory and access in your browser so that Blesta will run a system requirement check. Don't install, just delete the files when done checking the results of the system requirement check.

When I moved hosting companies, I used JetBackup to take a full website backup and then the cPanel Backup tool to take a backup of my database. I then uploaded the full website backup and imported the database.

When checking the logs at ../logs_blesta/ that directory appears to be empty due to not defining the new path when switching web hosting companies. I defined the new path and made it writable. I will give it 24 hours to see if it logs anything. I also noticed the uploads directory should be defined as there's a text field for it. Is this accurate?

I will go ahead and perform the 1-2 steps now and give it 6-7 hours before running steps 3-5.

Checking the dependencies, they all checked out good to go.

January 7, 2019

Hello,

Before anyone links me to all the threads regarding this issue back to 2013, I've already dug through a bunch and none of them resolved my issue. However, since I switch web hosting companies for my main site, I am getting the System Status error of "There are one or more cron tasks that have been executing for more than 60 minutes. View Automated Tasks." When I view the tasks, it just has the loading icon and that's it.

Tasks it's referencing: Cancel Scheduled Services and Suspend Services

Troubleshooting steps I've done:

Ran cron job manually
Disabled the tasks > Ran cron manually > Enabled tasks again
Removed cron job from cPanel and added it back
Spread out the times the cron tasks are ran at every 20 minutes
Upped the max_execution_time in PHP to 300
Allowed them to run on their own over a full 24 hour period
When running the cron jobs manually, there is no errors returned

Again, I'm not sure if I am missing something or doing something wrong but this only happened after I switched hosts.

Thanks,
Tyler

January 5, 2019

Just an update.. I restored a backup of Blesta before this thread was made and everything is working again. I am on PHP 7.0 as well.

January 4, 2019

11 hours ago, Paul said:

What is Rocket Loader and Auto Minify, are these 3rd party plugins? Did removing them resolve the issue?

They're features offered with CloudFlare. Auto Minify compresses file size of the source code of JS, CSS, and HTML. The Rocket Loader helps improve the paint time for pages that include JS. I did disable these two features as well. Again, everything was working perfectly fine before I switched PHP versions.

activa · January 3, 2019

3 hours ago, Kurogane said:

You need to disable Rocket Loader and Auto Minify.

January 3, 2019

No custom theme and it's Blesta 4.4.2.

January 2, 2019

Hello,

I am having issues since I switched from PHP 7.0.33 to PHP 7.1.25 and using the PHP 7.1 hotfix included. Whenever, I go to my AdminCP, this is all that loads there. None of the dropdown menus or anything works either. Taking a look at the developer mode console, I am noticing javascript errors as shown below in the images. Below are things I also did to troubleshoot before posting here.

Purged CloudFlare cache and put it in Developer mode.
Cleared browser cache.
Deleted Blesta cache (cache > deleted the directory titled '1').

Pretty much at this point, my AdminCP is not usable. I'm not sure with using CloudFlare that the resolving hasn't fully gone through yet or what.

Sign In

mobbdeep

Posts

Joined

Last visited

Days Won

Content Type

Profiles

Forums

Posts posted by mobbdeep

Actions redirecting to a blank white page

Actions redirecting to a blank white page

Actions redirecting to a blank white page

Blesta Soft Auto Installer

Blesta Soft Auto Installer

Blesta Soft Auto Installer

Blesta Integration 3.3.x (Advanced)

cPanel Module not updating passwords

cPanel Module not updating passwords

Cron tasks stuck

Cron tasks stuck

License key issue..

License key issue..

License key issue..

License key issue..

License key issue..

Cron tasks stuck

Cron tasks stuck

Cron tasks stuck

Cron tasks stuck

Issue with PHP and backend

Issue with PHP and backend

Issue with PHP and backend

Issue with PHP and backend

Issue with PHP and backend

Browse

Activity