Forum Replies Created

Viewing 15 replies - 16 through 30 (of 32 total)
  • Plugin Contributor Alain Schlesser

    (@schlessera)

    Hi @macken,

    The constant LIBXML_HTML_NODEFDTD should be defined by default starting from PHP 5.4 onwards, and since release 1.5, the plugin requires PHP 5.6+.

    Can you confirm that you are running at least PHP 5.6 or higher?

    I just tested on my system. What I’ve seen so far:

    wp redis cli hangs on my system as well
    – The command it tries to run on my system is redis-cli -h "'127.0.0.1'" -p "'6379'" -a "''" -n "0"
    – If I run that comand manually, I get the following output:

    Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
    Could not connect to Redis at '127.0.0.1':0: nodename nor servname provided, or not known
    not connected>

    – This means Redis was not active on that site. So I used valet to enable Redis: valet redis enable => this one also hangs!

    Given the above, my assumption is that Redis changed its CLI behavior (whether intentionally or not) and it doesn’t work as expected anymore.

    Plugin Contributor Alain Schlesser

    (@schlessera)

    @ashishjangra-1 The 50KB CSS size limit is unfortunately a hard limit by the AMP framework, specifically to disallow tools and practices that produces bloated sites.

    You’ll have to find a way to either manually reduce the amount of CSS that is being pulled in from Visual Composer, or switch to a leaner page builder/framework.

    Alternatively, you can still opt to not serve your frontpage with AMP if it seems too troublesome/costly to get the page to validate.

    Plugin Contributor Alain Schlesser

    (@schlessera)

    Hi @ariel-b,

    I assume from the above that the issue is currently resolved.

    Please open a new ticket in case something else comes up again.

    Plugin Contributor Alain Schlesser

    (@schlessera)

    Hi @adil1641,

    1.) The AMP form component allows you to define the success and error message through markup. If you don’t define them, a standard message is produced instead.

    See [AMP Form example] for an example of how to define the markup of the success and error messages.

    2.) The menu seems to be broken because of CSS that is not adapted to the new structure and its declarative nature. You’ll have to modify the CSS, maybe even provide AMP-specific CSS that overrides the default one.

    3.) Yes, that already works out of the box as well. However, on that particular site, there is so much going on that you hit the CSS size limit of 50KB. You can see the CSS size distribution if you use “View page source” on the page. The beginning of the markup will contain a big comment with the CSS size distribution. You’ll see that the main stylesheet does not fit into the 50KB size limit anymore, and that is why the page looks so broken.

    Plugin Contributor Alain Schlesser

    (@schlessera)

    The most likely reason this happens is because the HTML that is being produced by your shortcodes is being stripped because it is invalid according to AMP validation rules. You can check the validation errors on the validat
    The link on your site is probably https://debestetips.com/wp-admin/edit.php?post_type=amp_validated_url. If that link doesn’t work, you can find the correct link your AMP > Settings screen under the Reader mode option.

    Regardless of that, I’d like to note that the use of the Reader Mode is discouraged, as it is the legacy option and will be slowly phased out over time. The preferred approach is to use Transitional Mode and work on eliminating as many validation errors as possible. Once all validation errors are fixed, you can switch to Standard mode instead, which turns the entire site into valid AMP by default.

    Transitional mode has the main benefit that your site will still look similar to the non-AMP version, instead of having a completely separate design.

    Plugin Contributor Alain Schlesser

    (@schlessera)

    Did the mode setting perhaps inadvertently change? The behavior you describe sounds like your site was switched from “Transitional”/”Reader” mode to “Standard” mode.

    Can you please verify what mode the plugin is set to in the AMP > Settings screen?

    Plugin Contributor Alain Schlesser

    (@schlessera)

    @junpeizaki It looks like the Google AMP Cache has cached a non-AMP version of your “Pineapple Pen” page. As the Google Analytics script is a regular JS snippet on the non-AMP page, it will not get executed and not track the page view.

    I suppose the cache might have been generated at a time when the page itself was invalid and redirected to its non-AMP version.

    This might solve itself after cache expiration. I wanted to check what the max-age on your caching header is set to, but right now the cache seems to be forcefully disabled. Maybe this is because you were already trying to force a refresh.

    You can manually invalidate the page from the Google AMP Cache using the following procedure: https://developers.google.com/amp/cache/update-cache

    Keep in mind that the Google AMP Cache is not the only one. You can see the list of officially known AMP caches by reading the following URL: https://cdn.ampproject.org/caches.json

    Forum: Plugins
    In reply to: [AMP] Custom fields in AMP
    Plugin Contributor Alain Schlesser

    (@schlessera)

    @proteammaker Which mode of the AMP plugin are you using? If you are using the Reader mode, that would explain why not even print_r statements would work, as the Reader mode completely overrides the theme you are using.

    To actually make use of your theme, you’ll need to be in Standard or Transitional mode instead. Note: Don’t go for Standard mode right away, start with Transitional until you fixed all issues.

    Plugin Contributor Alain Schlesser

    (@schlessera)

    Regarding 1) you’d need to find out whether that was an error that was diagnosed in the past and is still shown although already resolved, or whether it is still an active issue.

    Regarding 2) I just verified the code. If you’re using the latest version of the AMP plugin, then it should only show the above warning if the ICU within the ‘intl’ extension is not up-to-date.

    You can verify the version of the ICU yourself in the output that you get from phpinfo(). For example, if you have access to the server’s shell, you can use the following to see the version:

    php -r "phpinfo();" | grep ICU

    On my system right now, this is what I get:

    ICU version => 64.2
    ICU Data version => 64.2
    ICU TZData version => 2019a
    ICU Unicode version => 12.1
    Plugin Contributor Alain Schlesser

    (@schlessera)

    I was looking into this just now, and it seems that you switched from Reader mode to Transitional mode, and the pages are offered as valid AMP pages as well.

    I suppose your issue is resolved for now?

    Forum: Plugins
    In reply to: [AMP] Incomplete Uninstal
    Plugin Contributor Alain Schlesser

    (@schlessera)

    For reference, here’s a link to the theme’s feature description of the AMP support: https://www.graphene-theme.com/graphene-plus/accelerated-mobile-pages/

    Forum: Plugins
    In reply to: [AMP] Incomplete Uninstal
    Plugin Contributor Alain Schlesser

    (@schlessera)

    Yes, the theme seems to include the AMP plugin directly. You’ll need to contact the support of that theme provider to discuss whether you can remove it safely, as I assume it might break if you try to do so. If it is bundled, it is probably a hard requirement for the theme to operate.

    You should actually be able to do a simple wp eval 'fvm_purge_all();'

    Plugin Contributor Alain Schlesser

    (@schlessera)

Viewing 15 replies - 16 through 30 (of 32 total)