Search    Register    Log In   

By on Mar 08, 2019 at 12:26 AM

Paginated toplists get a job done: they allow your users to page through very long lists in their entirity. For a full page list which is the primary page content, this is fine.

When the list people are paging is just a little box in a corner of the page, particularly if the box is below the scroll line, it's irritating that the entire page reloads to show the next toplist page. What we'd like to do is have a refeshless pager that just updates the toplist content quickly without affecting the rest of the page. That's what I've been working on this week.

In this sort of compact situation, a list of 10 different page numbers is usually less desirable than a simple previous/next navigation. Thus the initial type of navigation I've set up is two simple buttons, "Previous X" and "Next X" where X is the number per page. These buttons hide appropriately on the first and last page. I can add support for other forms of pagination on request.

To impliment using WSN 10.4.7 Beta 2, simply replace {TOPLIST1PAGINATION} with {TOPLIST1AJAXPAGINATION} in your template -- changing the number 1 to the applicable toplist number. I tested it out with the top 5 links box and it works fine there, except that it doesn't respect the sort top rated / most visited toggles since I haven't ajaxified those yet -- which I will do for the next beta, at which point I'll make the ajax version of the top links box be the standard template version.

This won't work on a toplist in the wrapper template at the moment, though if you need that let me know and it won't be too hard to support. It's uncertain whether it works on integrated templates from other scripts, if not then again let me know you need it. It's possible some advanced toplist options may not be compatible, if so let me know so I can look into it.

By on Mar 01, 2019 at 5:48 PM

Not too long ago, I added a twitter field for members to specify their twitter account. Given that WSN has had the facility to display twitter feeds for a long time (scripts.webmastersite.net/...tes/twitter-feeds-634.html) I decided today to make use of it by putting a twitter feed onto the view profile page.

Surprisingly, using the dynamic {MEMBERTWITTER} in the feed construct opener worked fine. I did discover that feeds were always displaying 5 items regardless of how many were requested, fixed that. Because people might enter their twitter handle as "wsnphp" or "@wsnphp" I also made {MEMBERTWITTER} normalize it to display without the @, which is what the feed needs.

The other, unrelated feature addition today is an option to include hidden items in bulk edit categories/listings in the admin panel. I also added number per page options to the filter area there. Theoretically I could also include the sort options with the filter but not sure if anybody needs that.

Finally, I removed the outer box from the view profile template. I did this because whenever there's a default box inside of a primary box in bootstrap it seems to cause the header text on the inner box to be white on white. And nested boxes don't look very good anyway.

By on Feb 20, 2019 at 7:31 AM

On the submit and edit listing pages, WSN has javascript that automatically adds http:// to the start of the URL if someone forgets to type a scheme. Submit/edit also has backend logic that attempts to fix URL inputs. Despite this, I came across a client site with all sorts of junk data in that field.

Some of it may be very old data from before WSN automatically prepended the scheme. Some of it probably comes from old imported data. To address these scenarios, I've made the 10.4.4 Beta 3 and later upgrades seek out and fix botched listing urls. It processes only 50 per upgrade in order to keep the upgrade from risking a timeout due to too many queries. But it'll keep running on each future upgrade.

To check what bad URLs your site has, you can run this PHP at Admin -> Miscellaneous -> Advanced:
$q = $db->select('url', 'linkstable', "url != '' AND url NOT LIKE '%://%'");
$n = $db->numrows($q);
echo "<p>$n invalid urls</p>";
echo $db->rowitem($q). " ";

I've also added new normalization logic on all fields intended for URL input (which was already present in some cases but not all). Now, when the input in such fields doesn't contain a '.' (which every URL on the public internet should contain, though intranet URLs may not), it's assumed to be bad data and the field is blanked. But to not mess with anyone using WSN for intranet purposes too badly, I made an exception for that so that when the URL contains 3 or more forward slashes it's accepted even if it doesn't have a dot. Thus "http://pgk-desktop/dir" is valid but "http://pgk-desktop" isn't and "http://random junk" isn't, as of this release.

This brought up an issue. Suppose the URL field is required, and somebody enters a junk value in the field. WSN needs to tell the submitter that their submission is incomplete and they need to fill in the URL field properly. This might sound like it'd be a simple change, but alas it ended up requiring a ...

Read Full Blog Entry

By on Feb 10, 2019 at 6:08 PM

10.4.2 brings some improvements to WSN's link checkers, especially the dead link checker. It now records and displays the time a listing was last found to be down, along with the number of times it has been dead. Should make it easier for you to see whether a link is definitely beyond hope or just experiencing some temporary downtime. There's a new "re-check" option so you can re-check selected links (re-check works for dead, reciprocal and content checks alike).

Also fixed some errors that were displaying when checking a site that has a bad SSL certificate. The bad certificates cause web browsers to advise people not to view the site and generally indicate an abandoned site, so I'm having it count them as dead.

Several other fixes also included. All the fixes will be backported to 10.3, some of them to 10.2.

Still running into some troubles with the new page speed tools on lesser-used internal pages. Hopefully I'll find all of those issues soon, meanwhile it's best to turn off the page speed options if your site is having problems.

By on Jan 31, 2019 at 8:18 AM

I decided to start the 10.4 series today. Continuing the recent development strategy, 10.4.0 is identical to 10.3.36 and they will begin to diverge with 10.4.1. This means we can finally stablize 10.3 so that no new bugs are introduced to it from now on. If you've been running 10.3 with automatic updates turned off, this would be a good time to turn the updates on as they're safer now. If you've been running 10.2 or earier, this is the time to upgrade.

The 15 of you who purchased access to the 10.3 series have been granted free access to the 10.4 series and should have gotten an email to that effect by now. Everyone else remains on 10.2, which is now the legacy series. I'll send an email to those people soon, with a summary of 10.3's advancements.

To those still running 10.1 or earlier, please upgrade to at least 10.2 ASAP because your site will become very buggy and potentially more difficult to upgrade as soon as your web host updates your PHP version to 7.1+ -- which will be soon, since older versions of PHP are being retired and will no longer get security updates.

Currently, the WSN versioning scheme looks a lot like Apple's Mac OS X versioning. In the future, I may switch over to a simpler scheme like Chrome and Firefox where each series is a new major number like 11, 12, etc.
<< May 2019 >>

Recent Comments