IIssues

WHMCS Lightbox Loading Image in Footer (Cloudflare Issue)

  • byJordan
  • August 8, 2022
  • 1 minute read

You might have seen a loading image in the footer of your WHMCS admin page. If you inspect the page, you’ll see it’s got some tags for the lightbox.

The issue is related to Cloudflare Rocket Loader, you can simply create a page rule to disable Rocket Loader on the admin pages or disable Rocket Loader altogether.

Source: https://whmcs.community/topic/309599-loading-spinner-admin-area/

Disable Rocket Loader with Cloudflare Page Rule

If you wish to disable Rocket Loader for a specific URL then you can use Cloudflare Page Rules using the following configuration.

DDrafts

WordPress Speed Up Analysis 2019-06-03

  • byJordan
  • June 4, 2019
  • 3 minute read

The following was a post I made on the WordPress Speed Up FaceBook Group. I thought it was worth posting here in-case someone else might be looking for something similar.

Olly Bee Excellent! First load for me was a white page without CSS being applied. Which is weird, I haven’t gone to the site before. So you might want to watch out for that, or maybe you were just making changes.

You’re not loading many assets which is great, mostly due to breeze combining css and js (assumption here since I see breeze.css). Just to note minification isn’t required for a great experience for customers. It’ll get you get you good scores on GTMetrix/PageSpeed but you’ll have to way usability for great gtmetrix scores.

Ue the built in Dev Tools in Chrome and look specifically at the Network page and waterfalls. Find items that are taking a long time to load, and see if they have any cache headers. Reload the page and see if they’re loading faster and if the cache headers appear.

When looking at all the items loading, the document items are usually html or PHP. This is where server resources come into play. If you’re getting higher load times on documents, it’s most likely due to caching not being in-play. Or it’s just a dynamic page (PHP) that can’t be cached (WooCommerce checkout, but even then LiteSpeed can use ESI blocks which makes it easier). If you can’t cache a page, then the server resources come into play. Specifically CPU, PHP its a CPU hog. Facebook tried to fix this by implementing compiled PHP using HHVM, but ditched PHP all together. Each time you have to load a PHP page, it has to be compiled by the server. You want to limit this as much as possible. WordPress deals with this fine as a vanilla installation. Once you add plugins, load times start to increase.

When I first loaded your portfolio page, I noticed it took about 3ms to load all assets. I looked at all the headers of each request and found that the main request for /portfolio had a x-cache miss and a high load time. Once I refreshed the page this load time went down. So it’s possible caching was put into play here either through Varnish or NGiNX fastcgi cache. Hard to tell, would have to look at your stack more.

If there’s caching in play, a header should appear. Most of the time this is configured, but not always.

Once your cache is filled, it looks like your pages load faster. So you might need to tweak your cache TTL. Which just tells the cache how long to keep things. This is great for static pages, but for anything dynamic it might cause issues. Most caching plugins deal with this automatically. Even CloudFlare does well with this if you setup the proper page rules. CloudFlare by default doesn’t do well with a WordPress site.

Aside from that, I see that .tff files aren’t being cached and have 400ms load tims where all your images are loading within 20ms which is great. That’s because most of them are from your StackPath CDN. And they’re small, which helps!

Another issue I noted is that your query stringed static assets aren’t being cached. Which is a common issue, so you can either enable this in CloudFlare via a rule. Or you can look at a plugin like Clearfy or Perf Matters. If you want to save money, there is code out there to simply just do this specific task.

Also, with the above plugins you can remove the wp-emoji-release.min.js and dashicons.min.css from loading. Again you most likely aren’t using them, but test anyways.

Hope that helps, Cheers!

UUncategorized

Adding APC to MediaTemple Grid Service

  • byJordan
  • November 29, 2010
  • 4 minute read

I have a client that wanted to start his own personal blog. He’s in the IT industry and wanted to use WordPress, he didn’t know what Shared Hosting Provider to go with. I suggested two, dreamhost.com and mediatemple.com

I don’t like shared hosting, why? It’s either slow at time for hours or always slow, so instead I just grab a VPS and pay the $30 or $50 month so my sites load fast. You could even ditch your Grid Service and go with a Dedicated Virtual, and achieve lighting fast page loads on your WordPress/PHP site.

Anyways, lets talk more about how to setup APC properly on the Grid Service. I mean lets really talk about it, because I always forget the steps.

You will need to first download the latest stable version of APC, I’ve had issues with the beta version and the stable version. But far less with the stable version. If you want to pick and choose which version to run visit the APC PECL Website directly at http://pecl.php.net/package/APC

I almost forgot, if you want to follow the instructions in this guide. You will need to have SSH access enabled on your Grid Service account. This guide will assist you.

http://kb.mediatemple.net/questions/16/Connecting+via+SSH+to+your+(gs)+Grid-Service

Once you have access and the URL to the latest stable release of APC (3.0.19 as of this writing). You will want to wget the file to the root of your account.

wget http://pecl.php.net/get/APC-3.0.19.tgz

Decompress and untar the archive, change directory to the extracted contents and phpize the module.

tar -zxvf APC-3.0.19.tgz
cd APC-3.0.19

Next you will want to run phpize. The phpize command prepares the PECL modules build environment.  Once you run phpize you will see something similar to the following:

server@n10:~/APC-3.0.19$ phpize
Configuring for:
PHP Api Version:         20020918
Zend Module Api No:      20020429
Zend Extension Api No:   20050606

Now we want to set the configuration options for the module. You will need to find out what version of PHP your Grid Service is running, you need to know the Major and Minor numbers. You can get this information from phpinfo, you will need to create a new file inside your sites html directory and enter the following:

Make sure the file has a .php extension and then open up a browser and view the file. You should be presented with something like the following.

You can see that we’re running PHP 5.2.14-2, the “-2” is more or less for MediaTemples reference.

Next you want to type out the following command and run it, pay special attention to the “-with-php-config” portion as this is important, make sure you find the right location of this file then run the command.

./configure -enable-apc -enable-apc-mmap -with-apxs2=/usr/sbin/apxs -with-php-config=/usr/local/php-5.2.14-2/bin/php-config

A bunch of text should scroll, hopefully no errors. Now we want to make the module so just type “make”.

xxxxxxx.com@n10:~/APC-3.0.19$ make
/bin/sh /home/xxxxx/users/.home/APC-3.0.19/libtool --mode=compile gcc -I. -I/home/xxxxx/users/.home/APC-3.0.19 -DPHP_ATOM_INC -I/home/xxxxxx/users/.home/APC-3.0.19/include -I/home/113041/users/.home/APC-3.0.19/main -I/home/xxxxxx/users/.home/APC-3.0.19 -I/usr/local/php-5.2.14-2/include/php -I/usr/local/php-5.2.14-2/include/php/main -I/usr/local/php-5.2.14-2/include/php/TSRM -I/usr/local/php-5.2.14-2/include/php/Zend -I/usr/local/php-5.2.14-2/include/php/ext -I/usr/local/php-5.2.14-2/include/php/ext/date/lib -DHAVE_CONFIG_H -g -O2 -c /home/xxxxxx/users/.home/APC-3.0.19/apc.c -o apc.lo

-------------CUT TO SAVE SPACE--------------

----------------------------------------------------------------------
Libraries have been installed in:
/home/xxxxx/users/.home/APC-3.0.19/modules

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------

Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).

Now we just need to make the appropriate directories for the module to reside. The directory you need to find is called “data”, if you follow these steps below you can navigate to the directory. Then make the proper directories, and then copy the module.

cd ~/
cd ../..
cd data
mkdir -p lib/php
cp ~/APC-3.0.19/modules/apc.so

The last step is to modify the php.ini and have PHP load the newly created apc.so module. (Note: in the second example, the ‘xxxx’ stands for your user number, you can find this by running “pwd”)

nano ~/../../etc/php.ini
or
nano /home/xxxx/etc/php.ini

Then just add the following lines:

extension_dir = /home/113041/data/lib/php
extension = apc.so

You should now have APC loaded into PHP, double check by going to the phpinfo page you made and search for APC. It should give you some information and configuration variables. Furthermore, if APC is not being loaded and shown on the phpinfo page, enable the error log (http://wiki.mediatemple.net/w/GS:Read_access_logs_and_error_logs) and see if any error messages are being generated.

Hope you enjoy!