doublesharp

I am still having the issue but have not had time to debug beyond enabling/disabling the caching plugin we use – this did not seem to have an effect.

Hi @kurtgarrison – you could try using the “find” and “replace” attributes to match the relative paths and update them with absolute paths. The functionality is a little limited since the interface is a shortcode. It would probably be a good idea to implement some action/filter hooks to make it easier to extend.

Hi @wordcrunch – the plugin isn’t compatible with the latest version of ACF. I haven’t had time to work on it (in quite a while actually) but hope to be able to update it soon-ish. Thanks!

Looking at this a bit more it seems like the 'acf/settings/load_json' filter is being used by ACFE, and the above really only affect the warning message if the settings files can’t be found, so not urgent but may still be useful. Thanks again!

@jonathanmoorebcsorg using the native module has much better performance. I would recommend using it, especially since it’s really easy to do.

Ubuntu/Debian
apt-get install -y php-redis

Centos/Redhat
yum install -y php-pecl-redis

Alpine Linux in Docker (because I just had to set this up…)

RUN set -xe \
    && apk add --no-cache --update --virtual .phpize-deps $PHPIZE_DEPS \
    && pecl install -o -f redis \
    && docker-php-ext-enable redis \
    && apk del .phpize-deps

@tbenyon what about providing a filter that can intercept and handle the user lookup via an API call (or… anything really) instead of using a DB query? My database fields are encrypted so I can’t use a direct query, but I can easily expose an endpoint that returns the same info.

Thanks!

It looks like it may not be compatible with 7.2 based on your report. The phpQuery.php file is included from here https://github.com/punkave/phpQuery and hasn’t been updated in 7 years so it’s not surprising it’s out of date.

If you have time to patch it or can find an updated library please let me know and I will try to get it updated. Otherwise I can try to update it when I have time, but I am fairly busy with other work right now.

Thanks!

It looks like you don’t have php-xml installed. Depending on your OS you can install it via something like sudo apt-get install -y php-xml for Ubuntu/Debian or sudo yum install -y php-xml for CentOS/Redhat. Make sure to restart Apache/php-fpm/etc before testing.

I think I figured it out – because the curl request doesn’t specify a language it is defaulting to Arabic, possibly because it comes first alphabetically? It would be nice if they defaulted to the language specified in the document, but….

You can use the h1 parameter to specify the language. In an incognito window I was able to change the language at the bottom by alterning the value. Use “en” for english.

[remote_content url=”https://docs.google.com/document/d/1Arn90KDkAxitPJi8pFjDde3HZCIcUdcd3Ai9fabHpb8/pub?hl=en”%5D

Curl is a command line utility for fetching webpages. The same library is used by PHP to download the HTMl shown in the shortcode.

I tried using the same shortcode on a page on my site and it does not have the footer in Arabic. Viewing website you linked above in the same browser *does* does it in Arabic, so my guess is that is related to WordPress/PHP/curl on your system.

See the test page here:
https://www.justinsilver.com/annabisset-co-uk/

What happens if you request the document using curl on the command line?

@patr100 I’m not sure what is going on, but the plugin is just using curl to request the URL and hasn’t been updated in 9 months. Is it possible the language on the google doc is set to Arabic? In the doc check File > Language.

• This reply was modified 7 years, 1 month ago by doublesharp.

It still doesn’t seem to be working… I just updated to the latest and am now getting out of memory errors. Removing the plugin fixes the issue. This was installed fresh from the WP repository.

Fatal error: Allowed memory size of 205520896 bytes exhausted (tried to allocate 262144 bytes) in /www/html/wp-includes/l10n.php on line 202

Fatal error: Allowed memory size of 205520896 bytes exhausted (tried to allocate 262144 bytes) in /www/html/wp-includes/load.php on line 677

The line number bounces around, but the errors do resolve when I remove wp-hide-post, so it does seem to be triggered by the plugin. Maybe an infinite loop?

• This reply was modified 7 years, 3 months ago by doublesharp.

This is fixed in version 3.3.13, thanks!

Hi @mardito,

The post meta option should be stored with username and password as “username:password”. When you specify it in the short code you give the key that the value is stored under, and it automatically inserts the post_id when fetching the meta value.

Thanks!