I just purchase Infinite Ajax Scroll after having difficulties trying to implement replaceState() with infinite scroll. I have managed to get everything set up to work correctly with the following code:
function infiniteScroll() {
// Init infinite scroll
var ias = $.ias({
container: '#masonry-filter',
item: '.post',
pagination: '.nav-links',
next: '.nav-previous a'
});
// Run isotope on additional load
ias.on('render', function(newElements) {
$(newElements).css({ opacity: 0 });
});
ias.on('rendered', function( newElements ) {
$('#masonry-filter').isotope( 'appended', $( newElements ) );
});
ias.extension(new IASTriggerExtension({ offset: 100 }));
ias.extension(new IASPagingExtension());
ias.extension(new IASHistoryExtension({prev: '.nav-next a' }));
}
As you may notice I'm using this along with Metafizzy's Isotope plugin. I am also using it within Wordpress and am hooking this onto the typical Wordpress pagination.
Although everything seems to work ok, it does not work the way that I had intended. My assumption was that it would work somewhat like http://tumbledry.org/, where after scrolling for some time, leaving the page, and clicking back in the browser, it takes the user to the exact same position they were in when clicking on the link. The plugin seems to be using replaceState() with the same url structure that WordPress uses by default for pagination (example.com/page/2). I don't know if this is done on purpose, or if it is a coincidence. As a result of this, when I click into a post and then hit the browser back button, it actually takes me to the example.com/page/2 page, where there is a button to show newer posts at the top of the page. It does not take me to the original posts page, nor to the exact spot on the page where the post is that I clicked (it usually takes me to the bottom of the page). In addition, when I click the button at the top of the page to show newer posts, it appends the newer posts to the bottom of the page (as you can see in my code).
I would like this to work as the tumbledry blog works. Where you can click on a link and then click the back button to get to the exact spot on the page that you were on (no need to load newer posts). Please let me know if this is possible, or if I have botched up the implementation. I would greatly appreciate any in depth information on the functionality because I'd like to figure out how I can get it working the way I want.
Infinite AJAX Scroll takes a different approach then the one on tumbledry. You say it loads newer pages but in a vanilla setup the items of previous page are prepended when you click the "load more" link. Your current rendered listener doesn't take this in account.
Also if you press back the plugin will get back to approximately the offset you were, but not exactly. That would require a more advanced setup with server-side code and would defeat the purpose of this plugin: simple progressive enhancement for infinite scroll without any server-side coding.
In case you really want the exact working like tumbledry, its author has a detailed post about his implementation: http://tumbledry.org/2011/05/12/screw_hashbangs_building
Infinite AJAX Scroll takes a different approach then the one on tumbledry. You say it loads newer pages but in a vanilla setup the items of previous page are prepended when you click the "load more" link. Your current rendered listener doesn't take this in account.
Thanks for the insight here.
Also if you press back the plugin will get back to approximately the offset you were, but not exactly. That would require a more advanced setup with server-side code and would defeat the purpose of this plugin: simple progressive enhancement for infinite scroll without any server-side coding.
I understand that this won't be perfect, but it always brings me back to the very bottom of the page (footer area which is underneath the infinite scroll). I take it that you need to use a button to trigger the Infinite scroll, while using the history feature?
In case you really want the exact working like tumbledry, its author has a detailed post about his implementation: http://tumbledry.org/2011/05/12/screw_hashbangs_building
I brought this up because I had already been through his post and attempted to roll my own infinite scroll with no success.
IMHO the UX for the history functionality, although eloquently incorporating WP server-side functionality, is slightly odd. Landing on a Wordpress paginated page and having to click a button to show the posts that were originally on the page, when you had clicked off of it. The plugin is great and I know you are making use of the technologies/features available to you. I think I'm just going to stick to using the basic functionality instead of using "history" for now.
Related
I would like to confirm what effect this CSS code has on the homepage of a wordpress website.
.lazy { display: none !important; }
Many thanks for explanations.
I have noticed images in the homepage are being blocked from being displayed which is why im asking this question.
The CSS code itself, prevent any element which has it from being displayed on the screen.
Due to its name, it may be used to enable something called lazyload (you can read about it here).
lazyload is usually used for several reasons:
Remove the pressure of loading many images at first; sometimes images are placed at the end of the page so the client won't see it at the top of the page, with lazy loading trick it. You can prevent those images from being loaded, and force them to load only the moment your client reach them by scrolling or other events so it cause page loading improvements (because the page is now lighter)
For making some visual effects; almost everywhere you need the image to be hidden and after some juggling or some specific events it is shown (like wp-admin and sub-menus, which will be shown if you hold your mouse on or click them)
etc
Recording to the reasons; I guess your kind of codes (which will be handled in client-side and client browser) does not fit the first reason and may be used for the second one because for the first reason it is better (and I guess it must) implemented on server-side. Why? Because in your code, the image is loaded and be will there and just not shown because of the CSS code
This was all I know but if you want a more specific answer you have to say where you saw it in WordPress, in a plugin, wp-admin, template, etc...
Hope the answer becomes handy for you
1 – I have a search and filter form on my mobile site (480px and below) made with Search and Filter Pro plugin. Here’s the screenshot showing what I mean:
If you click on “Pokaż filtry” filters will appear. The problem is that when you expand it and just click “filtruj” (filter), the “Pokaż filtry” button will stop working – you can click as many times as you want but it won’t expand anymore (it becomes unclickable). Everything will start working again after refresh.
Second problem is very similar to the first one. At 480px and below, when you choose any option and click “filtruj” the whole search form will dissapear. Everything will start working fine again after refresh.
At resolution 960px to 480px there’s a button to show sidebar.
There’s also a Search and Filter form. When you use it, you can’t close the sidebar – the button just stops working (becomes unclickable).
These issues are 100% caused by Search and Filter Pro plugin. When I deactivate it, everything works fine. Most likely it's a conflict with theme.
Here's my site - http://gromocje.pl/
Does anyone have any idea how to fix it? I feel like I tried everything... I've never seen such a issue.
$('.otfm-sp__title').click(function() {
replace with:
$(document).on('click', '.otfm-sp__title', function() {
Reference & more info - stackoverflow.com/a/29674985/2245806
I'm designing an extension for Google Chrome, and I'd really like to earn a little cash from it (if possible) so I'm not eager to post the code in its entirety. I hope this isn't a prohibitive limitation for my question.
I'm injecting a content script into all websites as part of my extension, and part of the content script includes a touch-sensitive overlay; it's an invisible HTML div that's been assigned a swipe listener. The idea is to add swiping functionality to every website on which the script is run.
I'm having issues, though, with the overlay seeming to "die" on certain pages, especially after scrolling down the page. It registers swipes flawlessly all across google.com- scrolling or otherwise- but, for example, seems to die on engadget.com after scrolling down the page a bit. (After scrolling a bit more, it often starts registering swipes again.) Doing something like opening the console (F12) also causes it to start registering swipes, and refreshing the page (to the same place the object was before) lets it start registering again.
The HTML/JavaScript I'm utilizing for the overlay is this:
$("/<div class = \"touch_sensitive_overlay\" style = \"top:40%;opacity:1;position:fixed;height:247px;z-index:99999;width:50%;left:50%;border:2px solid black;\"></div>").prependTo('body');"
I'm using the jQuery Mobile library to register the swipes.
Any helpful insights would be profoundly appreciated.
Update:
A solution was proposed by Sumurai8, and was successfully implemented. The document was listened to for scrolling, and- whenever scrolling occurred- the overlay was removed from the injected HTML, then immediately re-injected. In this way, the overlay is continuously "active," and responds to input on all websites. Thanks for the good thinking, Sumurai8.
You could try to have a small script that does 'something' with the overlay when any element is scrolled. E.g. $('*').on('scroll', function() { $('#overlay').css( {'top': '0'} ); } ); and see if that fixes the problem. While in itself it doesn't do anything, it might make Chrome render your overlay again.
As you said in the comments, removing the overlay and re-appending it will force Chrome to render it again too.
I'm trying to display all node_edit form neatly within a lightbox without any of the excess content I don't want. No sidebars, footer, header, nothing. Just the content. So I created a page-node-edit.tpl.php file.
I have two problems daunting me, but for now I'll only mention the first since its more important.
1) From any drupal page, clicking on the "edit" link for the node doesn't activate the lightbox like it should. Instead it clicks-thru the link as normal.
With jQuery in the header I added a rel attribute for the lightbox to the links, but the box still doesn't activate. I tested the lightbox on a link I hardcoded into the page, and it activated just fine. For elements generated by Drupal, like the node edit link/button the problem seems to be timing.
I think the rel attribute needs to be built with the page, with the link, rather than appended onto it. The catch is, the link lacks an id and class, so I don't see how the hook_alter_link() function can help me.
I'm willing to try anything. Perhaps someone has done this before? Opened a node/edit form within a lightbox.
Any suggestions would be greatly appreciated.
I've seen the Modal Frame API used in a few modules (Node Relationships uses it to do something very similar to what you're doing); might be helpful...
http://drupal.org/project/modalframe
I have one web page in ASP.NET and I want that page to be disabled until the whole page loading process gets completed.
One way is to activate a lightbox without content that will dim the whole page and then on the body onload event hide that lightbox.
Lightbox is a like having a modal window above the original window, and is used to preview pictures and other content. It could easy be modified to do what you want. Just activate a lightbox with no content and then hide the lightbox when the document is loaded.
This is a strange requirement and I would be interested in finding out your reason for doing this. Is there a problem or error that is ocurring. Perhaps you think the best way to prevent the error is to freeze the UI until the page loads.
I think that you should edit your question and describe what the underlying issue is. There might be a better way to improve your page.
I've seen this done with a simple overlay before.
Basically an iframe and a div that covers the page and has a high z-index is output at the beginning of page render. This is styled so it greys the page out and it also makes everything non-clickable. Then, once the page is loaded, a simple bit of javascript can be used to remove the div and iframe (or just set their styles to make them disappear).
I've also seen people attempt this issue by manually iterating over all controls on the page in JavaScript and disabling them. This is a horrible way to attempt it :)
The jQuery BlockUI plugin is another good option with lots of customization options.