basvandijkk

Hi Rosel, we’ve looked at our Nginx settings again haha..

This is currently what we have:

# WebP support
location ~* ^/?wp-content/.*\.(png|jpe?g)$ {
    access_log                  off;
    log_not_found               off;
    expires                     max;
    add_header                  Vary Accept;
    try_files                   $uri$webp_extension /wp-content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$request_filename&wp-content=wp-content;
}

# Pass all .php files to php-fpm, make sure the backend variable has been set in the server block that includes this snippet
location ~ [^/]\.php(/|$) {
    fastcgi_pass                unix:$backend;

    # regex to split $uri to $fastcgi_script_name and $fastcgi_path
    fastcgi_split_path_info     ^(.+\.php)(/.+)$;

    try_files                   $fastcgi_script_name =404;

    set                         $path_info                  $fastcgi_path_info;

    include                     fastcgi.conf;

    fastcgi_param               PATH_INFO                   $path_info;
    fastcgi_index               index.php;

    proxy_read_timeout          60s;
    proxy_connect_timeout       60s;
    fastcgi_connect_timeout     60s;
    fastcgi_read_timeout        60s;

    fastcgi_param               PHP_VALUE                   "memory_limit=768M \n                     
    max_execution_time=60";

    fastcgi_intercept_errors    on;
    proxy_intercept_errors      on;
}

the problem is that when we use $uri =404; behind the try files when targeting the webp-on-demand.php file there are no new webp images being created. We are only able to let them generate when not using the $uri =404;.

Do you have any idea what could cause this?

Well initially I’ve used another plugin, but I have changed the Nginx settings according to the ones stated in the FAQ of this plugin.

• This reply was modified 5 years, 8 months ago by basvandijkk.

Nice! @roselldk great work man!

Okay so for checking whether the plugin works out for my site I should just use picture instead for now. And before going live with it, switch back to my current settings(after having used the bug-fix patch).

Btw probs for the quick response!!

maybe if you would hook into the filter aal_whitelist_options. This is for what options need to be logged. I don’t know exactly what kind of data you want to log.

Try searching for apply_filters in the plugin.

• This reply was modified 5 years, 9 months ago by basvandijkk.

Is it getting deleted from the server as well? And If not, is it still activated within the database?

Are you able to receive any other emails from your website. If you would use the wp_mail function, is it able to deliver them to the email address you are providing?

• This reply was modified 5 years, 12 months ago by basvandijkk.

@sarumbear That currently is not a possibility. In order to achieve this you’ll need to edit plugin core files which ofcourse is not recommended.

Hey Ewout, I purchased the plugin. I’ve added my custom version of the invoice. Do I need to activate it somewhere? Since its not being overwritten yet.

Thats great, Stefano! Glad I could help.

I’ve searched within the plugin for any possibility to disable the database insert from within a theme or child theme but no success. But in case of you commenting it yourself.

The following line can be commented to disabled the plugin from hooking into the filter wp_login_failed.

Line: 76
File: /wp-content/plugins/aryo-activity-log/hooks/class-aal-hook-user.php
Example: //add_filter( 'wp_login_failed', array( &$this, 'hooks_wrong_password' ) );

It would be a great addition to be able to select what notices need to be stored within the database.

• This reply was modified 6 years ago by basvandijkk.
• This reply was modified 6 years ago by basvandijkk.

Why don’t you just use a plugin that prevents users from having X amount of failed login attempts? This plugin is just meant to log activities within your WordPress installation, not prevent them from happening or not logging them.

Kind regards,

• This reply was modified 6 years ago by basvandijkk. Reason: added komma
• This reply was modified 6 years ago by basvandijkk.

The following element is causing this.
This is not a WooCommerce element so either your theme/some other plugin is causing the grey overlay to be visible after adding an item to your cart.

<div class="owp-cart-overlay" style="display: block;"></div>

You mean as in the address details aren’t being filled out automatically within the fields when choosing to enter a creditcard manually?

For example most of our users login on the topic page, and I noticed that your plugin never even shows any of the logins unless the user specifically uses the wp-login page.

What login method are you using?