Exavior

Just in JavaScript. When we fire the new function you made available (on AJAX page load) we need to be able to tell what page the user just loaded.

• This reply was modified 4 years, 12 months ago by Exavior.

Just to clarify, I need the page number for use in JavaScript, not as a display element on the page.

We just need to know what page of content was loaded so we can track a viewer’s progress.

Is there a way to expose the page number so the new function can have context? For example, being able to fire a tracking code on page 3.

I can confirm that the AJAX link back to page 1 from page 2 is now working after updating to the latest version.

Thanks for adding the ability to have a function callback for AJAX page switching. That is working well for me as well.

The code I had to change is inside $(window).hashchange() and specifically inside of “success” and it needs to pass a variable (for now). That is not something I can setup using bind.

Inside that function I am calling my own custom “reloadAds” function. I also need to pass your value for “hash” to my function so I can determine which page is being loaded, as the ads don’t need to reload for the first time Page 1 loads, only every time a new page is loaded or the user goes back to Page 1 (which may be an issue now that it’s possible to navigate back to page 1)

It’s possible there is some other event I can tie into, but it’s vital that thigns fire after the new page content has been injected into the DOM.

Here is a code sample.

	// Bind the event.
	$(window).hashchange( function(){
	//set the value as a variable, and remove the #
		var hash_value = window.location.hash.replace('#', '');
		$.ajax({
			url:window.location.pathname + window.location.search + hash_value,
			dataType:'html',
			type: 'post',
			success:function(res){
				$(".jps-wrap-content").html($(res).find(".jps-the-content").fadeIn('slow').addClass('done'));
				
				// My function below
				reloadAds(hash_value);

				$('.jps-slider-nav a').bind('click',ajaxNav);
				if (jpps_options_object.scroll_up) {
					$('html, body').animate({
						scrollTop: 0
					}, jpps_options_object.scroll_number*1000 );
				};
			}
		});
	});

Really all that is needed is for the plugin to allow users to define an event that fires when pages reload, ideally only when new pages load, not the first load. But it needs to fire after the new content has loaded, so it can’t just fire when Next or Previous is clicked.

And hopefully the fix for page 2 to 1 is done soon, as this is holding up one of our projects. We can’t launch until it’s fixed. So the $60 spent on your “pro” plugin may quickly become a $60,000 loss…

I just got it yesterday, how would that not be the latest version?

When you say you will work on navigating from page 2 to 1 (something that astounds me that was broken) can you just share the code you changed so I can manually update? I’ve had to edit your code to make somethings work, so sadly I can’t just update. I needed to fire a function when the AJAX has loaded so ads can update, so I had to modify the code to support that. Still trying to find a way to not have it request CSS files as we are trying to keep HTTP requests down.

I was able to get the navigation working with AJAX to address part of the issue. Looks like any kind of 3rd party JS errors will stop this thing in its tracks and prevent proper navigation. By eliminating a 3rd part JS issue it now consistently goes from page 1 to page 2, 3, 4, etc using AJAX.

However, you still can not go from page 2 to page 1. a 404 is thrown for https://www.mysite.com/mypost/mypost (no hash) and the location changes to https://www.mysite.com/mypost/#mypost which is not a valid option.

You really need to add a field in the settings for JavaScript events that fire once the AJAX content has loaded, as many people will need to load or refresh ADs when this happens. (not just when nav is clicked, but when content has loaded)

And the CSS issues are still a headache. I’m going to have to modify your plugin to not load any of the CSS files and redo everything by hand.

Thanks, that code did the trick on our new site, so we should be able to launch it without having to roll back the plugin.

I’ll start implementing that snipit on all our production sites on Monday so our maintenance team can move forward with scheduled plugin updates without having our sites stop functioning.

Thanks again for the quick replies and support. Really appreciate it! (can’t possibly stress that enough, we averted a major financial disaster. Had that gone into production )

The brackets are processed on our end to replace them with values from the originating page’s query string, so they need to be exact.

We can’t change our formatting, as we run a large number of sites, each with thousands of pretty links that we’ve built over many years using this plugin, so we need a future-proof solution.

Any chance of making this a toggleable feature in the plugin settings moving forward? We work with a number of solutions that address dynamic parameters in URLs using french brackets, so this is not really that much of an edge case.

For now I’ll try adding the filter to our new site.

Would adding this filter to sites that are running an older version of your plugin cause any issues? If possible I’d like to update our codebase with the filter prior to updating those plugins. Otherwise we’ll have to time the plugin update with a new build.

Thanks for the help!

Pretty Links Version 3.0.8

Field getting mangled: Target URL

5 weeks now. Please support this plugin.

3 weeks since this emergency issue was posted, 1 week since I last reached out. Still worried, still an extremely serious issue. I’m not seeing any other way to reach out to the developers, so this seems to be my only hope. Very disappointed.

Still extremely urgent. Hoping this plugin has not been abandoned by the developer at this point.

Please help.

This is still an emergency. Been 5 days. Really hoping to hear back.

Thanks,

/Chris