Tony

Hello, ea-php* is created by the cPanel team and as of this moment they don't even support PHP 7.2. We're able to offer PHP 7.2 as CloudLinux already supports it which is why it shows up as an option.

In that case you're probably best to open a support ticket. If your phpinfo file is not showing the extension it sounds like something on your account is overriding the extensions you have set.

It sounds as though your PHP does not have the memcached extension enabled. Login to cPanel go to select php version then check the memcached extension off and save it. Then your PHP should have the memcached extension and Wordpress should detect it.

At this time you'd need to have our team look at the web server logs to determine why the Python application does not work. We're working with the Litespeed team on a more elegant solution which will work similar to that of PHP's error_log file. At this time though no estimate on when that'll be available but it is definitely something that will be coming as Python and Ruby applications become more popular on our shared web hosting they need ways to debug them without opening support tickets.

Since you're using Cloudflare there would be no point in having the Litespeed plugin minify anything as Cloudflare will do it for you and not use your CPU cycles like the plugin would.

alt-php versions are the ones that allow extension control which we've offered for a long time. Recently though cPanel introduced their own multi PHP system which while inferior to alt-php in terms of flexibility is offered because users coming from other hosts may have previously been using it. For compatibility reasons we offer the ability to use it as well.

Just one other update to this, we've updated how Memcached is handled and now also support Redis: https://blog.hawkhost.com/2017/10/20/introducing-cpanel-application-manager-redis-support/ . You may want to give this another try and see if you can get either to work now.

For Wordpress you'd be best to use the Litespeed page caching plugin. For phpbb3 I don't believe there is a plugin for that so you'd want to use Memcached or Redis if either are an option.

Very old topic but I'd like to mention we now support the ability to start up your own redis server: https://blog.hawkhost.com/2017/10/20/introducing-cpanel-application-manager-redis-support/

We'll take into consideration our process limits but I should mention that realistically no normal use case could a user max out their process limit before hitting memory limits. Here's what you could utilize in both cases: 20 processes - 51.2MB per process 50 processes - 20.48MB per process. We see even the most lightweight Wordpress installation use 30MB per process. Typically installations are over 50MB+ in usage due to the extra plugins being utilized. There can be some memory usage improvements from using PHP 7.1 instead of the typical 5.6 (plugin compatibility continues to be a problem for some users). Unless you're launching a lot of tiny processes that use no CPU/memory I wouldn't even worry about process limits.

I looked on their site and I see no mention of a limit on concurrent connections nor a process limit although I'm sure one is set do you know the limit? As far as our limits we have a limit of 20 processes and 25 MySQL processes on our shared web hosting packages and more than that on our semi dedicated packages. We are always evaluating if our values are appropriate still of course but you also need to remember it's shared web hosting. These limits are in place to create a more stable environment and having extremely high and inappropriate limits could lead to an overall poorer experience even though your control panel may say you have more available resources. The limits we have in place are strictly for PHP, Perl, Ruby, Node.JS, Python etc.. We have extremely high limits on our web servers and you could easily serve over 2000 requests/sec. In our blog post https://blog.hawkhost.com/2015/07/22/super-charge-wordpress-with-litespeed-cache/ we were able to make a Wordpress site go from 5.46 requests/sec to 1839.98 requests/sec simply by utilizing caching. This strategy could be used on many other web sites as well or even just utilized if you expect a large amount of traffic in a short period of time.

We have plenty of users with various applications utilizing memcached. I'd suggest opening a ticket and asking it to be assigned to me and I'll see if I can determine why it's not working. Unfortunately a lot of applications don't give clear instructions how to use memcached feature when the memcached server has to be accessed by socket. Considering the amount of servers where more than one user is on it utilizing ip/port with no authentication is a very bad idea. It would be easy for another user to read and even write data to your memcached instance.

That's exactly the format you'd want to use so you're good and shouldn't run into any issues with SPF record problems going forward.

The best solution would be to add an include to your spf record to include "_spf.arandomserver.com" . This encompasses all our mailing IP's so you'd never need to worry about it again. Any new account with us actually has this record added automatically.

Which feature did you end up utilizing?

Our Amsterdam location was unavailable for a short period of time but right now we have plenty of capacity and can easily now add capacity as necessary. You should see an option to order hosting in that location. For the actual migration it's typically best you disable features that there is user input as information will get out of sync. What users typically do is order hosting and then disable their forums, forms etc. and ask for our team to migrate the site. Once our team has migrated the site the user enables the features again on our systems. Then any new data is only added to our systems. Along with that if your host uses cPanel we can migrate accounts in just a few hours typically (unless the host is slow or blocks backups). So you don't even need to worry about domain changes if you don't want to. Your sites sound fine in a shared environment so you shouldn't need to worry about that aspect. They'll be very fast on our servers, I have no doubt about that.

At this time it's not possible to change the configuration of memcached.

We switched from utilizing randomized ports for users to using a unix socket on user accounts. Any application that supports Memcached should allow for unix sockets the same way it can use ports. You'd use the address: unix://(socket location we give you) We'll have someone from our team update the image to reflect the unix socket change. We missed that while updating the blog post to mention it's handled using sockets.

Hello, I can't make any guarantees on this but maybe this will put you in the right direction. We utilize Litespeed and I've seen a few ways thrown around on how to do this: <FilesMatch "\.(gif|png|jpe?g|svg|svgz|ico|webp)$"> SetEnvIf Origin ":" IS_CORS Header set Access-Control-Allow-Origin "*" env=IS_CORS </FilesMatch> <FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css|css|woff2)$"> Header set Access-Control-Allow-Origin "*" </FilesMatch> So in this case they're doing it for specific types. There is also a discussion on the Litespeed forums on other ways to accomplish this: https://www.litespeedtech.com/support/forum/threads/header-set-access-control-allow-origin.8346/

You'll need to create an email account to send from then since you're not using the mail() function then you're probably best to utilize a mailing library. Here are a few examples of them: http://swiftmailer.org/ https://github.com/PHPMailer/PHPMailer If it's a third party application a lot of them already can interface with SMTP. You just need to tell them the SMTP server and a username and password.

Based on the deepstream installation instructions you'd require your own server so it would not be possible to deploy it on a shared hosting account.

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.

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: https://pecl.php.net/package/memcache . 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.

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.

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.