Implemented Suggestion to The Plugin

[semprot]

I have some suggestions :

Features :

• Admin can set different TTL to each cache setting.
  Reason :
  Some data such as "Nodes" are very rarely changed. Admin can set high TTL to "Cache Nodes".
  Some data such as "Forums" / "Threads" / "Posts" can require lower TTL, to ensure the data is fresh enough.
• Full page guest caching, with independent TTL setting.
• Cache who is online, with independent TTL setting.
• Cache online staff, with independent TTL setting.
• Cache "new post" page result, with independent TTL setting.
• Cache "new profile post" page result, with independent TTL setting.
• System test should not do all cache operators automatically. But only selected "Cache Operator".

Guide
Better explanation about what are cached in "Cache Nodes", "Cache Forums", etc.
So admin can decide what should be on, and what should be off, how many TTL shoule be set on each cache setting

 

[Fillip H.]

I can look into a separate TTL setting, however I want to point out one thing:

System test should not do all cache operators automatically. But only selected "Cache Operator".

This is absolutely and categorically NOT going to happen, because only testing the selected cache operator is part of why the vBulletin version of this mod had the power to crash sites with no way of recovering unless they disabled plugins via config.php.

Let's say you wanted to use XCache. Now as you may or may not know, XCache by default does not work. The default configuration, if you attempted to use it in vBOptimise, would crash your entire forum. You not only had to be using the correct method of serving PHP pages (i.e. NOT fcgi), but you also had to manually configure the .ini file settings for XCache before you were ready to use it.

If you saved XCache as your operator of choice to test it, your forum was now 100% unusable. Here's the steps an admin would need to take to recover their site:
1. Disable all plugins via config.php
2. Go to the AdminCP, disable vB Optimise in the plugins & products
3. Re-enable plugins (to minimise forum downtime)
4. With vB Optimise disabled, go to the vBOptions and choose another operator
5. Save, and pray to the baby jeebus this particular operator worked. If it didn't, GOTO 1 and repeat.

It is absolutely vital that admins see the test results of ALL operators, so they can make an informed decision on which operators to enable.

There's another form of "crash protection" new in DB Optimise, namely that if the operator failed with a fatal error, the system resets the operator selection to None, to ensure smooth running of the forum.

 

[semprot]

This is absolutely and categorically NOT going to happen, because only testing the selected cache operator is part of why the vBulletin version of this mod had the power to crash sites with no way of recovering unless they disabled plugins via config.php.

Thank you for explaining

 

[DragonByte Technologies]

Hello semprot,

This ticket has now been closed with the status Implemented.

We hope your issue or question has been addressed to your satisfaction. If not, please feel free to re-open it by clicking this link.

If you have any further issues or questions, please feel free to start a new support ticket via the button at the top of every page.

Thank you!