So I want to crawl information about the following 2 products:
1. http://www.dollargeneral.com/product/index.jsp?productId=86154836
2. http://www.dollargeneral.com/product/index.jsp?productId=58607576
Product No.2 offers "save 5% on all order with Auto delivery"
Product No.1 doesn't
When I crawl this page, the "div" about the offer part doesn't show up, so I think this information is loaded by ajax.
Now my questions is: after using chrome dev tool to check the "Network" using XHR filter, both URLs only send 1 request that contains seemingly useless information.
So where is the offer information coming from? Thank you!
These are two different products. One simply has the offer attached to it while the other does not. Some products include the offer and others don't.
Related
On my page I would like to output all records of a specific folder
but the number should initially be limited to a certain quantity (to reduce the loading times). With a "Load more" button further records should be loaded.
Does anyone have a hint on how I can achieve this?
I have already found several approaches on the web in connection with AJAX, but since I'm not familiar with this yet, more questions than answers have emerged ...
For info: I use an own Template Extension / Distribution under Typo3 9.5.8
Thank you in advance for any help!!
The state of the art solution is the AJAX solution, where you load only the required records from the server and modify the page on the fly.
Another option would be an URL parameter which is evaluated by your extension.
With the parameter the full list is shown,
without only the first N and a button with the link to the same URL including the parameter for the full list.
Make sure the paramter is handled correctly and generates another cached version of the page. (keywords: cHash)
As you now have two pages with partially identical content: don't forget to tell the searchengines that the short variant should not be indexed.
You could use the Paginate Widget like documented here: https://docs.typo3.org/other/typo3/view-helper-reference/9.5/en-us/typo3/fluid/latest/Widget/Paginate.html
By overriding the paginate template file and only rendering the pagination.nextPage link, you could load the nextpage via AJAX.
I'm using LocomotiveCMS on a project and I have some doubts on what's the best approach when dealing with ajax requests to the same site.
I have a Content Type for a model called reviews. There can be plenty of review entries, so I'd like to show 20 per time, then allow fetching other 20s by hitting a button (like a 'load more' button).
What is the best approach for this? I was thinking on making a custom API controller in order to do that. It would have to find the right type of content entries based on the content type for reviews. Then add some regular javascript that hits that controller and add the new set of reviews based on a mustache template. Does it make sense or is there something that LocomotiveCMS has in order to accomplish such type of tasks?
Update:
I got an answer from the LocomotiveCMS google group. Basically somebody suggested to create a liquid template that looks like a json. For the full answer go to https://groups.google.com/forum/#!msg/locomotivecms/vJKDtl81v7E/IEwOR9hhLjMJ
Since its related to AJAX technology so I thought this is the best place to ask.
I am displaying 5 articles at a time to the user on my website and when he clicks 'Next' I load the next 5 articles using AJAX without loading the entire page.The result is that he always stays at the same page .
One of my friend told me that website ranking depends on number of page views and I think this obviously reduce my page views.
Should I not use AJAX then?
(This might be a stupid question but I seriously have no idea about ranking and SEO so please help)
By loading your content dynamically Google will not see the entire page. Only the part that is loaded. So, if Google rank is important for you it's better to not use an infinity loader.
Actually it is not a good idea to navigate page using AJAX. Consider a scenario,
display 5 articles first then by clicking Next button, next 5 items will load and so on... by using this the page will not become Search engine friendly.
in this case search engine can't locate your contents exactly and will crawl only initial contents.
but with some efforts you can make ajax navigation search engine friendly.. see example here.
Currently the scheme of loading content of page dynamically is not a good idea for SEO friendly web page but try considering other ajax page navigation schemes that might help the page to make dynamic as well as search engine friendly.
some suggested ajax navigation schemes are listed below,
http://nickjohnson.com/b/how-to-make-ajax-search-engine-friendly-seo
http://ajax.rswebanalytics.com/
http://www.symatix.co.uk/articles/ajax/search-engine-friendly-ajax-navigation
I have a MediaWiki page set up in my company's intranet.
I would like to get the content of a section in a specific page using MediaWiki API (through AJAX).
I would like to refer to the section by its title like 'General' and refer to the page by its title as well, like 'Licenses'.
Is it possible somehow?
The only thing I could achieve is referring to the page by its title and refer to the section by a number like this:
http://mywiki.local/wiki/api.php?format=xml&action=parse&prop=text&page=Licenses§ion=1
But let's say I create a new section before 'General' I would have to update all my AJAX URLs that queries this page. So this isn't good enough.
I couldn't find any working solution for this. Any ideas?
You can do this by first retrieving prop=sections to get the list of sections and their numbers:
http://en.wikipedia.org/w/api.php?format=xml&action=parse&prop=sections&page=License
Then make your original request, with the section number you figured out based on the previous request.
Keep in mind that two different sections can have the same name.
I have a shopping cart I want to embed in a widget/iframe on other users sites, I see three ways of doing this each with drawbacks. Here are options from estimated most to least work.
Recreate interactive shopping cart UI in javascript widget then pass values to server script with AJAX, variables are passed to the main site, when user clicks "checkout" the user is then redirected to main shopping cart site with variables populated from what the entered in the widget.
pros: complete experience
cons: most work to complete creating UI and AJAX request.
Somehow detect if user is coming to shopping cart via iframe, if this is the case have alternate code that opens new window when user clicks "checkout" redirecting user to secure page and getting variables from cart via AJAX to populate final checkout.
pros: mid amount of work, must do AJAX request to get variables from shopping cart to populate final checkout
cons: can we easily detect if site is being accessed from a user within an iframe on another site?
complete entire checkout process inside iframe/widget.
pros: least ammount of work, just embed cart in iframe
cons: will not show https in browser user may be reluctant to purchase
What is the best option?
If you could provide a bit more information, maybe I could offer you an even better option. For starters, what have you built this application with (languages/framework)? Also, would you say your application's functionality is similar to Shopify's in that you allow users to host e-commerce sites through your service? If not, tell us a bit more about your application.
Here's a quick response to the options you provided.
option 1: the only real option as I see it. Whether you're embedding the shopping cart in specifically an iframe or rendering it onto the user's page as part of a template, you should be navigating the customer away to your main site to complete the checkout process. Or at least give them a lot of screen real-estate to work with (a sizable modal for example).
option 2: is messy. You can tell if a request is coming from a remote form (like an iframe) by appending url parameters. But taking the approach you're suggesting with this doesn't make too much sense.
option 3: too heavy unless you take a modal-approach like what I mentioned in response to option 1.
That being said, if you are building an application like Shopify, you should be able to build a template for each user's website that has a section dedicated to displaying a shopping cart pertaining to the current customer's session. No iframes or widgets necessary with this approach. But again, it all depends on the use cases of your application.
If your only concern with Option 2 is detecting if your content is being loaded within an iframe, you can do that with JavaScript by using "top.frames.length" or "top === self."
For example, you could show or hide different conditional form content, or a different submit button, using the following:
if (top.frames.length == 0) {
// Show content if not embedded in an iframe.
document.getElementById('embedded-content').style.display = "none";
document.getElementById('unembedded-content').style.display = "block";
}
else {
// Show content if embedded in an iframe.
document.getElementById('embedded-content').style.display = "block";
document.getElementById('unembedded-content').style.display = "none";
}
As you've stated, the first option is the best in terms of user experience and the most likely to achieve the highest possible conversions. How much better the conversion is compared to the next best solution cannot be objectively measured, as it involves recurring customers, your own brand name, the kind of products, etc. Since the conversion rates will directly affect you (and your company), it's wise to make an estimate first to see if your efforts spent will be worth it in the short and long term.
The second option is the sweet middle ground; you still get brand recognition and customers will have some security reassurance (via address bar); (i)frame detection is easily done by a simple JavaScript comparison: top === window. However, you're losing the continuity and hence likely lose some conversion. If this risk is manageable, I'd go for this option in the short term.
Not being able to see the security certificate directly via the green lock makes the third option the least desirable. However, not all is lost; by clever use of imagery you can still gain some trust with your end-user, as outlined in this image, which is part of a great article from Smashing Magazine.
Your decision should be based on:
what can be done in the short term
what should be done in the long term
how important is secure visual cues to my potential customer
time / money spent on either solution versus revenues (break-even analysis)