cjhaas

Hi Jordy,

I’d love to help with a beta, you can email me at chris at vendiadvertising dot com. I know a couple of other people that might be interested in it, too.

Nginx has basically one server-wide config file that’s analogous to apache2.conf and as you can imagine the web process cannot write to this file. Some people (like me) also use the “sites-available” and “sites-enabled” pattern (like Apache) for individual sites while others just throw everything into the main config. For those that use the “sites” pattern, those config files are also not writable by the web process either and you’d have a hard time determining what is what anyway.

As Pothi also said, there’s no .htaccess file that can be dynamically written to and read from and even if there were you’d still need to issue a reload or restart command to the nginx process which a web process wouldn’t (or at least shouldn’t) be able to do. The best you can really do it point people at a recommend test configuration which is what we do on our plugin:

https://github.com/vendi-advertising/vendi-wordpress-caching/wiki/Nginx-Config

We ran into this today, the fix appears to be pretty simple. We did not test this with PHP 5.x but PHP officially recommends that if you need to support both 5 and 7 then you should remove the type hint and only use Throwable if you only want to support just 7. The changes that we made can be seen here:

https://cjhaas.com/blog/2017/02/24/one-event-calendar-time-ly-exceptionerror-problem/

I went ahead and just did it on my repo.

This diff (scroll all the way to the bottom to modules/tables/views/tables.php) shows the basic changes that need to be made. Instead of rendering HTML directly via $this->_twig->render() you need to first create a template via $this->_twig->createTemplate() and then render it using $template->render(). You’ve got that in two places and the changes are pretty easy.

The bigger change is the recommendation to not use Twig_Autoloader anymore and instead use composer. The third function change in this file no longer checks for the class and assumes that the autoloader is taking care of things for us.

https://github.com/vendi-advertising/pricing-table-by-supsystic/commit/98393b94fb86d3fc363e71dc78d1d8018809ced4#diff-f1281deca99498d1b8f81ab6c5d678ee

In pts.php you should just add this to the top of your code:

    if( is_file( dirname( __FILE__ ) . '/vendor/autoload.php' ) )
    {
        require_once dirname( __FILE__ ) . '/vendor/autoload.php';
    }

Lastly, after your merge you just need to run composer update once and you’ll get the most recent version of Twig 1.0 in your vendor folder.

From WordPress’s SVN standpoint you’ll still want to check Twig in however you’ll probably want to ignore the vendor/twig/doc, ext, test folders as well as the loose files in the twig folder.

Do you have a git repo for a PR? If not, I can temporarily add your previous version to mine and commit a patch that shows the changes.

• This reply was modified 8 years, 2 months ago by cjhaas.

Can you try using the fully-qualified class name?

\Vendi\Cache\api::do_not_cache()

Hi Mark,

I was wondering if you had a chance to test out 1.2.1 yet? All of our tests show that the issue is resolved but I’d like to hear it from you before I close this one out.

Thanks,
Chris

Thanks Robswaimea! We were disappointed when we heard that Wordfence was removing the feature but we were very happy that they allowed us to continue it!

Mark contacted us directly but this should be addressed in 1.2.1 which was just released.

Hi Mark,

I’m sorry to hear about this. We had one other user with this issue on one of their sites but everything else has been okay so far. We do know of one issue related to PHP5, is that what you are running?

Thanks,
Chris

Hi foley2013,

We just released version 1.2.0 that addresses this typo.

Thanks again for catching that!
Chris

Hi Roger,

We just released version 1.2.0 that has this feature as part of the public API. You can now clear the cache via the static method:

\Vendi\Cache\api::clear_entire_cache()

Thanks,
Chris

Hi wordpresslover7, (Santa brought me a Windows 10 BSOD that I had to play with) but we just released version 1.2.0 that implements this feature.

https://www.ads-software.com/plugins/vendi-cache/changelog/

The preferred way to tell Vendi Cache to not cache a specific request is via a filter:

add_filter( \Vendi\Cache\api::FILTER_NAME_DO_NOT_CACHE, '__return_true' );

We prefer the filter because it is overridable which makes testing easier. If you want, however, we still have a static public method that you can invoke (that actually still calls the filter):

\Vendi\Cache\api::do_not_cache()

If you have any questions about this just let me know!

Thanks,
Chris

Hi wordpresslover7,

We are planning on releasing an incremental update next week sometime (probably Tuesday or Wednesday) with this and a couple of other smaller but important features and tweaks.

Thanks,
Chris

Thanks webby1973!

I’m hoping to have an updated release by the first of the year and possibly a beta for multisite installs, too. There’s a lot of comments in the code regarding weird edge cases for MS but those might be from a couple of years ago and no longer relevant since WP has been focusing on MS a lot in the past couple of releases. Are your sites running a fairly recent version of WP, 4.6 or even 4.7?

Once I get the next release or beta out I’ll post something to this thread so if you subscribe to it you’ll get a notification.

The code also lives on GitHub so if you’ve got time to hack away I’ll gladly take a PR!

https://github.com/vendi-advertising/vendi-wordpress-caching

Thanks,
Chris

Hi Roger,

We’ll be adding that in very soon! Unfortunately do to namespace conflicts the function’s name will change so you’ll need to update your code. I’m hoping that Wordfence will keep that static method around and call a global do_action() instead that I can hook into but that would be on Wordfence’s side to do that.

Thanks,
Chris