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.

By on Jan 30, 2019 at 1:45 PM

Time to revisit the color-coded map pins option.

First, I thought it'd be a good idea to make google maps use the same marker image as Open Street Map. That way you can customize it (marker.png in your theme images), and more importantly it removes the dependance on google's long-depreciated charts API which was being used to generate the google maps pin images dynamically before -- that API could go dark any day.

The tricky part was to maintain support for the colored map pins option without having to create 10 new images for different colored pins which would be a pain for you to customize. To achieve this for google, I ended up using some tricky CSS. Basically I have it append a color number to the image with marker.png?color=2. Then the CSS img[src="https://www.quietplease.org/attractions/templates/images_blog/marker.png?color=2"] { filter: hue-rotate(60deg); } alters the color of just the ones with ?color=2.

I was hoping this would make it easy to port the colored pins option to OSM. No such luck, somehow the CSS trick doesn't work with OSM. Seems as if the markers aren't actually img tags in the DOM for OSM. Who knows what they are? Chrome's element inspector should know and it says it's an <image> tag with a weird xlink:href attribute containing the url. But image[xlink:href="https://www.quietplease.org/attractions/templates/images_blog/marker.png?color=3"] { filter: hue-rotate(120deg); } didn't work. A search result suggested escaping the colon, but that didn't work either. Even using the image tag's id didn't help, so there must be something mysteriously keeping it from acting as part of the page DOM.

Eventually, after reading novel upon novel of documentation, I realized the only way to get this done before I die of old age is to use something much like the google chart image-generating API. Rather than use the depreciated one, I've built a new one into WSN that uses your marker.png and applies color changes via gd/imagemagick in a script...

Read Full Blog Entry

By on Jan 29, 2019 at 3:56 AM

Today's release has two major sets of new features. First, there's a suite of page speed tools on a new page speed settings page. Most of these tools were discussed in the last blog entry. I've been able to boost one of my WSN installations a 97/100 speed ranking on the google mobile site speed test with these page speed tools, with no significant adverse effects. Of course, they make it a pain to edit things so they ship off by default and should only be enabled when your site goes live and you're no longer changing it regularly.

There's also a new file browser tool. This is similar to cpanel's file manager, but simpler. It allows you to do some basic file editing / deleting / uploading without FTP. While it does make things easier for a hacker who has access to your admin account, a hacker who has access to your admin account already essentially controls your server -- so be sure to use a strong password, limit the admin permissions of other admins you can't be sure will use strong passwords to only areas they need, and consider IP restrictions.

I've also fixed an issue with some old version upgrades that was causing youtube embeds to have mixed content errors on https sites (this wasn't affecting most https sites, just those who originally installed certain old versions). Also noticed recently that the BB codes and smilies links in the comment message composition help were being blocked by chrome's popup blocker, so I changed them to open in full new pages... which also has the advantage of working on mobile, though it's not pretty.

Finally, I discovered that when WSN tries to download a remote web page (for whatever purpose) it was failing on gzip-compressed pages in some circumstances. I changed the curl code to handle gzip compression to fix this.

By on Jan 23, 2019 at 2:20 AM

WSN has some page speed tools -- html minification, javascript minification, css minification -- but these tools are limited. While they combine many files into one, they don't combine every possible css/js file into one. While they handle most of the styles/scripts on most pages, they don't automatically handle every obscure page. And if you've added custom scripts/styles to your website that you found around the internet or wrote yourself, WSN doesn't make any attempt to combine or compress those.

Thus I've been working on a more complete and generalized page speed tool -- although it'll probably be more complex to operate and more prone to failing on unusual unforseen situations. This tool will be able to work in other scripts like wordpress or any php script with slight adjustment. A hook passes it the final output of the page, which it then parses to extract all stylesheet and javascript files. It builds minified caches of each css/js file at a rate of one file per page load, via an 1x1 transparent PNG image worker thread inserted in the page -- grabbing each interpreted URL (normalized for relative urls etc) via cURL/fopen. Once all of the page's css resources have been cached, it then combines them into a single cache file. Same for javascript. Then it replaces the first stylesheet reference in the page with the combined style cache, and the first javascript reference in the page with the combined javascript cache. All other style/javascript inclusions are removed from the page. Then the page HTML is minified for output.

In the process of building this, I discovered that WSN's modifyendoutput plugin doesn't actually modify the very end output -- instead, it modifies just before conditionals processing. Applying HTML minification there would break WSN conditionals, so I've added a new pluggable function modifyultimateoutput that processes at the very end.

Anyway, this page speed script is proving a lot more complex than it initially looked but I think I'm with...

Read Full Blog Entry

By on Jan 17, 2019 at 3:57 AM

A month or so ago, I made a change to how the children of categories with special rewrite URLs set work. Previously, the children didn't take into account their parent's special URL -- since then, the children have automatically used their parent's special URL in calculating their ancestry path part of the URL. For example, if a category named "One, Two" has the special URL https://site.com/onetwo/ then a child URL is now https://site.com/onetwo/child/ whereas previously it would've becoming a numeric category URL due to the special character (comma) in the parent category name.

Turns out this had an unwanted effect in a certain situation. Someone was giving some of their top level categories special URLs of the form something.html, which resulted in subcategories being somethinghtml/child/, but they wanted the subcategories to be something/child/. To work around this, I just put in an exemption so that special URLs that contain .html are not considered by their children.

The major new feature in today's release is the zoom level constraints options on the maps settings page. Most of these options were previously available as tweaks, but the tweaks were incomplete and failed to explain the meanings of the zoom level numbers. You can restrict the range the auto-calculated starting zoom value will fall within, and you can also restrict the range the user can manually zoom to. Also elevated the coloredpins tweak to a setting. And elsewhere on the maps settings page, added some javascript to automatically hide options not available to OSM when using OSM instead of Google Maps.... btw it should be easy enough to make the zoom constraints and colored pins work with OSM if anyone lets me know that they're using OSM and would like those options.

In other news, I've finally redesigned the offers system to be fully mobile-friendly on the submit/edit page. This will not overwrite your current offers input html, only applies to new installs. I need to start thinking of a way t...

Read Full Blog Entry

By on Jan 09, 2019 at 11:07 PM

10.3.31 contains a few more speed improvements, less drastic. It also fixes three little bugs:

When using the horizontal admin menu with a non-bootstrap front end theme, the menus weren't working because it wasn't including the bootstrap javascript. Important fix since it left people unable to navigate their admin after they install a new theme or change menu type in certain ways.

In the guided start, the settings page suddenly shrunk to a smaller size halfway down. Fixed the missing closing tag that was causing that.

In the listing bit, the conditional that checks whether the viewer has permission to email the listing was mistakenly <IF {THISHASPERMISSION[canemail]}>. I've corrected that to <IF {THISMEMBERHASPERMISSION[canemail]}>. Now the email link only appears in appropriate contexts, and this fix also speeds pages a bit because it removes the unparsed template variable. I discovered this problem when I was working on optimizing settingsreplacements and saw it was trying to process {THISHASPERMISSION as a potential setting. I've made this fix apply automatically to modified templates, since it's simple enough to do so, so you won't need to edit your customized listing bits.
<< July 2019 >>

Recent Comments