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>";
for($x=0;$x<$n;$x++)
{
echo $db->rowitem($q). " ";
}
die();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 major rewrite of the required field checking code and everything it touched to be more object-based. I've tested every scenario I can think of, so I'm hoping this hasn't created any new bugs in the required field checking... but changes of this complexity usually have hidden consequences.
Another issue: it wasn't entirely visually to a submitter which field they failed to fill in, at a glance, in cases like this where the HTML5 required marker isn't there to cause a pre-submit browser prompt. I've changed it so that WSN applies the class text-danger to the entire offending table row, which gives the row red text on standard bootstrap. (I wanted to use .bg-danger for a red background instead, but hours of attempts where it worked on some rows but not others eventually gave way to the realization that the bootstrap .table-striped class overrides it for every other row and there's no way around that without defining a custom non-bootstrap css class override [which I don't want to do because I'm trying to make it easy to change bootstrap themes].) For now this only gets applied for listings, and only when using the field manager compatible templates. But I think it's a big help in making it easier for people to spot their mistake and complete their listing submission.
More problems have continued to crop up with the page speed combine resources option. CKeditor uses relative paths that are proving too diffcult to automatically rewrite into absolute paths, so I've decided to just exclude the submit/edit pages from the combining for now. Will have to continue to be on the lookout for deep internal pages that contain slightly different javascript from most pages. It would be nice if I could generically solve the path issue, but I'm not seeing any way to combine javascript files from different directories that use relative paths without needing to rewrite them (whether automatically or manually). Path change auto-application is unlikely to work with files that are already minified, too.
Found the comments lastedit field was mysteriously a text field instead of integer and that was causing an error with PHP 7.2+ on previewing listings. Fixed that for 10.3 and 10.4.