Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • I’m not related to the plugin development, but I had the same issues you have.

    The first one is related to the plugin is somehow not able to load the css and javascripts for the gallery, properly. You can either debug the plugin and find a fix, or better include the link or button that load that gallery page as no-ajaxify, in the AWS options. You must include the class or id (depends if your are using the free or pro version). That will cause your gallery page being loaded completely, not by ajax approach.

    The second issue seems to me that you are not configuring the ajaxify container properly. Again, it will depend on the version of the plugin you are using, but if it is the free, you just specify the ID, if it is the pro version, you specify the ID or class, but you need to prefix it with ‘#’ or ‘.’ respectively (css selector) as you would do with jquery.

    Hope this helps anyone having the same misunderstanding complications.

    Thread Starter mariodlg

    (@mariodlg)

    Hi manishkrag

    After 9 months, this issue came back to me, I continued using the free version of the plugin since the pro version was giving me this issue.

    By looking at the code, I realized that settings are not compatible between the free and pro version.

    What was causing the issue is that the pro version expects the ajaxify container to be either a class or an ID, so you, the user, need to specify that in the selector (prefix # or . respectively), which is not the case for the free version.

    So this reported issue is not a reail issue, thanks for your time!

    Please mark this as resolved.

    • This reply was modified 8 years, 4 months ago by mariodlg. Reason: typos
    Thread Starter mariodlg

    (@mariodlg)

    Thanks manishkrag.

    I’ll try to be specific here.

    When I activate the free version of the plugin, everything works great.
    After I deactivate the free one and enable the Pro version, the site breaks showing the following text in the screen:

    News – My Site
    window._wpemojiSettings = {"baseUrl":"https:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":".png","source":
    {"concatemoji":"http:\/\/localhost:8888\/wp-includes\/js\/wp-emoji-release.min.js?
    ver=4.4.2"}}; !function(a,b,c){function d(a) ... a lot of stuff here ...

    which is part of WordPress, but got broken because of a failure.

    I can see the following error in the console:

    Uncaught TypeError: Cannot read property 'top' of undefined

    The portion of the js code that is running is this:

    } else if ( 1 == aws_data['transitionfade'] ) {
    	$content.fadeToggle('slow', function() {
    	$('.aws-overlay').remove();
    	$content.html(contentHtml).fadeToggle('slow', function() {
               load_inbuilt_script_file(rootUrl);
               load_extra_script_file(rootUrl);
               if ( '' != $('#ajax-search a').attr( 'href')) {
    	      jQuery('html, body').animate({
    		  scrollTop: jQuery(jQuery('#ajax-search a').attr( 'href')).offset().top
                  }, 2000);
    	   }
           });
         });
      }

    Lines 160 – 173, AWS Pro version 1.5

    The line with problem is this one:

    scrollTop: jQuery(jQuery('#ajax-search a').attr( 'href')).offset().top

    I may say that I don’t have the search field in my site, so no ‘#ajax-search’ exist in the dom.

    Hope this may give you some clues.

    If you think you need to see the entire code, or to make some test or investigate with my site, just let me know, I can give you access.

    Thanks for any help in advance.

    Thread Starter mariodlg

    (@mariodlg)

    Thank you @digico

    I was able to reproduce the issue in my local environment. If I test the staging site alone in other server, everything works fine, since it is a clone of the production one. I haven’t made any changes yet.

    However, when I deploy the staging copy into a subfolder of the production one, the issue appear, even in my local environment. So here is what I’ve tried so far:

    Main site ( a few pages ) is in the root folder /
    Main WordPress root is under /cms
    Staging site (a few pages) is at /staging
    Staging WordPress root is under /staging/cms

    Main site /cms/.htaccess file content:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /cms/
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} !^/staging/
    RewriteRule . /cms/index.php [L]
    </IfModule>
    
    # END WordPress

    Staging site /staging/cms/.htaccess file content:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /staging/cms/
    RewriteRule ^staging/index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /staging/cms/index.php [L]
    </IfModule>
    
    # END WordPress

    apache.conf section for the document root:

    <Directory /home/vagrant/mysite>
    	Options Indexes FollowSymLinks
    	AllowOverride FileInfo
    	Require all granted
    </Directory>

    If looking at these files makes you realize my problem, I will be completely grateful!

    Regards!

    UPDATE:

    Forgot to mention that the issue is that the Staging site is using the wp-config.php of the main site. I’m sure of this because I set wrong parameters in the wp-config.php and the Staging site says “Database error: Error establishing a database connection”, so it is not using its own wp-config.php

    Thread Starter mariodlg

    (@mariodlg)

    Thank you Digico for your prompt response.

    I’m not using different prefix, and the databases are exactly the same. I cloned the production one and replaced all urls and content with the new staging urls.

    Also I haven’t changed the .htaccess, that means both .htaccess are equal since the staging site is also a clone of the production one.

    Something is telling me right now that this is wrong. So I’m going to read about the .htaccess rules WordPress uses and see if I can find the culprit.

    About your suggestion on using other sites to test, I think I can replicate the problem in my local environment. The only thing I cannot replicate may be the subdomain, but I don’t see how that can be part of or causing the problem.

    Thanks again!

Viewing 5 replies - 1 through 5 (of 5 total)