• Content count

  • Joined

  • Last visited

  • Days Won


Tony last won the day on March 22

Tony had the most liked content!

About Tony

  • Rank

Profile Information

  • Gender
  1. Looks like a similar solution to phpbb where they refer to the php memcached extension as Libmemcached. As for checking if it's working you'd be best to open a ticket. Although for most applications if it's not working they typically end up hanging or throwing an error.
  2. Looking at that guide they are installing the memcache extension not the memcached extension. Unfortunately I don't foresee us offering it as an option after PHP 5.6 just due to the fact it was last updated in 2013: . I don't foresee us offering the memcache extension in PHP 7.0 or 7.1 simply because even our vendors (cPanel, CloudLinux) are not doing it.
  3. The problem is it is utilizing the memcache extension which is only available until PHP 5.6. I'd suggest contacting Xenforo and seeing if there is a way for it to utilize the memcached extension which would be necessary if you're running PHP 7.1.
  4. In that case if you're comfortable with SSH what I recommend doing is we kill the current memcached instance and then start it back up. So if you login to SSH you can run: ps axu | grep memcached Then you should see something like this: 607 802829 0.0 0.0 66600 940 ? Sl 11:07 0:00 /usr/bin/memcached -B ascii -m 64 -s /home/memcachedtest/.hostdata/memcached.sock You'll then want to kill the process so in my case I'd run kill 802829 Then if you do another ps axu | grep memcached you should no longer see the memcached instance running. You will then want to turn it back on in cPanel then hopefully this time around it's operating properly.
  5. Our DNS servers are remote so if the web server goes down then DNS would be served. We also utilize anycast for our DNS infrastructure and have DNS servers in numerous diverse locations. We do this for performance and redundancy purposes.
  6. Our original setup was over IP/Port but had switched it to socket and updated our documentation. I updated the text description for that as well now and we'll see about just updating the pictures as well. As for the issue at hand I'd suggest opening a ticket if you still cannot connect to the memcached socket as the code there shows it supporting it. So it's possible the memcached instance on your account is not starting up properly or something similar.
  7. The reason we do not offer a traditional IP/port is because anyone on the same server as you could read your memcached data. This would be a security risk which is why it's a socket that exists only inside your own accounts Cage meaning only you can access it. I want to clarify one thing the recommended extension is memcached and not the memcache extension. The memcached extension is actively developed: The memcache extension is not: The last release is almost four years ago. Looking at their code directly I believe we can make this work with sockets. What you can do is use the following: unix:///path/to/memcached.sock The reason I'm coming to this conclusion is $this->memcached->addServer(trim($parts[0]), trim($parts[1])); They are calling the PHP extension and the documentation for addServer is here: and it accepts sockets on the host and you set the port to 0. That should make everything work when you utilize the Memcache extension in PHP 5.6. Unfortunately looking through the phpbb forums there is no support for the memcached extension meaning you cannot utilize PHP 7.
  8. You don't need to bother throwing up an index but it really doesn't hurt uploading an empty index.html file so it's not a directory listing when you visit the site.
  9. The short answer is the new subdomain will be seen on the web and it'll work fine. The long explanation is: The idea of a public_html folder is really an old way of thinking. The web server is capable of showing a site regardless of the folder it is in. As a result of this cPanel now automatically places any new subdomains/addon domains below your public_html folder. It allows for easier organization and makes so you don't have a case of the content of one subdomain/domain loading from the primary domain of the account also. You can also be even more flexible and do things like: blogs/ blogs/ forums/ forums/
  10. Hello, I believe we resolved the issue with that specific system and are investigating why our internal monitoring systems did not pick up the problem on it's own. Sorry about any inconvenience this may have caused.
  11. Unfortunately you would need us to delete the SpamExperts account for the add-on domains as the only other way to remove them is actually to remove the add-on domain itself from cPanel currently. What you'll need to do is open a ticket with our support team and it'll be escalated to our system administration team who will handle deleting the domains from SpamExperts for you.
  12. 1. Typically when you have session problems it's due to your IP address continually changing meaning your session is no longer valid. 2. What URL are you accessing cPanel from? This suggests none of the images or css are loading which is very strange. Regardless I'd highly recommend opening a ticket as our support team should be able to quickly assist you with this.
  13. This would affect anyone using the plugin as we do not change the plugin in anyway from the standard plugin Cloudflare makes for cPanel. As for changes unfortunately we just don't know as we're not sure what Cloudflare are going to do to resolve the problems we've found.
  14. I've confirmed the server you're on when using PHP 7 does load ioncube for both web based and CLI based requests: PHP 7.0.13 (cgi-fcgi) (built: Nov 10 2016 07:46:27) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with the ionCube PHP Loader (enabled) + Intrusion Protection from (unconfigured) v6.0.6, Copyright (c) 2002-2016, by ionCube Ltd. with Zend OPcache v7.0.13, Copyright (c) 1999-2016, by Zend Technologies What is probably happening is you've modified PHP via either a php.ini or in your .htaccess file and you have code like maybe: suPHP_ConfigPath AddHandler application/x-httpd-php56 .php Or similar lines causing you to override your accounts system php.ini settings and when you switch to say PHP 7.0 you're not loading ioncube at all or maybe even not loading PHP 7 but instead still PHP 5.6 but with PHP 7.0 system ini settings. So I'd recommend going through looking for this and commenting out any of this code then see if switching between PHP versions then results in Ioncube loading properly regardless of PHP version. If it still does not work update the ticket and ask it to be escalated as we'd need to search through your account to see where you're overriding PHP settings.
  15. The problem with forwarding email and I'm not sure if gmail has changed at all but they consider the server you're on as partially responsible for the spam. So if you're say forwarding a lot of spam to them they may opt to block the server you're on. They may also simply consider it to have a poor reputation and be very aggressive and flat out drop mail over a certain threshold. I'm assuming they'd also put your domain you're forwarding in as part of the equation so a lot of spam from it and it could end up in the same situation as our servers. As far the SpamExperts SPF problem it may be more aggressive as far as failures compared to say Google. You could disable SPF checking via SpamExperts filter settings or alternatively if you find it's a common domain just disable the check for it. For the filtering the any header I believe is what you'd want and just have it make sure the spamexperts header line exists (check one of your messages for it to confirm the exact text). I would of course suggest when you enable this you test it immediately just to make sure it's working.