Webmastersite.net

Search    Register    Log In   


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.


By on Jan 05, 2019 at 6:58 PM (Edited Jan 05, 2019 at 7:04 PM)

Today I've been working on how WSN performs, especially with large pages and especially when not using query caching. Specifically, when I was trying to show 132 articles at once on a page at scripts.webmastersite.net/...nistrative-tasks/switches/ it was taking as long as 30 seconds to load.

Delving into that, I found several culprits. First, when WSN is configured to only allow one vote per person per listing, there was a query that checks whether the viewer has already voted on a given listing. This was running 132 times for the 132 articles, so I changed it to pre-cached a list of all listings voted on by the viewing member (1 larger query that runs a lot faster than 132 small queries). Then I found a similar situation with the saved listings system, it was running a query on each article to see if we've saved that article -- so I cached that with a single advance query too. That's 262 queries eliminated and twice as fast a page load, but still not fast enough.

Next, I noticed that it was querying category #5 once for each article displayed. Turns out this was a parent being queried for {LINKCATNAMEWITHNAV} navigation which is shown in search results but still in the link bit template all the time even when conditionalized out. I made that method cache the categories so it only queries each category id once. That saved another 131 queries and 4 seconds.

After the above, the article processing in the middle of the page was reasonably fast -- but the page as a whole was still unacceptably slow. This turned out to be mostly because of some inefficiencies in processing huge pages (132 articles is a lot of text, even when it's just listing bit stubs). The funcreplacements() call which replaces the {FUNC_ generic function template calls was taking 3 seconds to run. This was because of hundreds of {FUNC_SHOWICON[edit]} calls running redunantly for every article. I've optimized that away so it only runs the showicon function on each icon once.

Applying...

Read Full Blog Entry


By on Jan 03, 2019 at 8:30 AM

The first release of the new year contains a variety of changes.

There was a postal code autofill issue. Normally when you enter a postcode WSN automatically fills in the city and state if they haven't been entered yet. Discovered that wasn't working when OpenCage was your geocoding provider, because WSN was looking for the city name in the wrong place. Fixed that.

Most of my time was spent on the calendar system, particularly rewriting the event joining system to use a new _eventrsvps table. Added an RSVP caps option and did a lot of work on the calendar templates.

I've finally re-enabled the HTML minification option. I never did find a new library that avoids the <option value=""> -> <option> transformation mistake, instead I've simply added a de-transformation at the end which changes <option> back to <option value="">. There's nowhere in WSN that intentionally uses <option> to mean the value should be the label, so it should be safe... hopefully.

Also added a javascript minification setting. Previously javascript minification was always on unless the developermode tweak was enabled. Changed the developermode tweak so that it turns off all 3 types of minification now. And in order to add a warning about developermode overriding settings, I ended up adding BOOL versions of the {TWEAK template variables to enable conditionals that check if tweaks are enabled... e.g. <IF {TWEAKDEVELOPERMODEBOOL}>Warning:This value is overrridden by the developermode tweak!</IF>

For the future, I'm pondering what the best way to do a development / production toggle would be. I'm thinking something on the front page of the admin panel that can temporarily disable every option that gets in the way of debugging when you toggle it to development mode. Then when you put it in production mode it turns all the temp-disabled options back on and suggests a list of additional things (like URL rewriting and minification) that...

Read Full Blog Entry


By on Dec 25, 2018 at 11:43 PM (Edited Dec 25, 2018 at 11:47 PM)

As a last minute Christmas present for you, I've enhanced WSN's advertising system in several ways.

First, I've added device and country targeting. Device targeting allows you to set certain ads to only show on mobile or only show on desktop/laptop. This is useful when you have differently sized or differently targeted ad code for phones versus desktop. Country targeting, which depends on IP geolocation being turned on, is useful if you have certain ads or ad networks that are only good for a particular country or set of countries. For example, if you're advertising an offer only available in the USA you can limit the ad to only show in the USA so that your international visitors are served something else potentially more useful.

After those changes, the frequency percentage system had come to look absurdly complicated. A set of percentages that adds up to 100 in one country might not add up that way in another, thanks to country targeting. Likewise with device targeting your ads in a slot might add up to 100% on desktop but 120% on mobile. It was clear that percentages were not the ideal way forward.

Also, I found that WSN's ad display logic was regluarly repeating display of the same ad until it could bring that ad's impressions count up to the desired percentage. That's bad, because an ad may have been created much more recently than a different ad or percentages may have been changed. Essentially, this was causing new ads to be the only ones shown for long periods.

The solution to both issues? A new frequency system that calculates relative odds for display of each ad. First, WSN determines which ads are eligable to be viewed by the person viewing this ad slot on the current page (removing any ads from other ad slots or targeted at other devices or countries from consideration). For each remaining ad, it calculates a weight: a random number between 0 and the frequency number you've specified. Whichever ad ends up with the highest weight gets displayed. This ...

Read Full Blog Entry


By on Dec 23, 2018 at 3:38 AM

10.3.26 brought a whole slew of new mobile fixes/enchancements too numerous to go into detail on, so let's talk about the non-mobile changes.

The first change you'll notice is that the release notes are now on permanent display on the front page of the admin. This way, your site automatically updating itself doesn't prevent you from seeing the list of what changed.

While doing the mobile stuff, note I moved the delete boxes on the edit listing/category/comment/member/field/help pages to the bottom and made them collapsed by default. This has a dual purpose: it reduces the amount of scrolling needed to get to the more commonly used content (especially important on mobile), and it serves as a confirmation of intent to delete since it takes two clicks/taps now.

Recently I removed a bunch of dead IM fields like AIM, Yahoo, MSN messenger. Now I've repurposed that section as "social" and added a twitter field. This should soon enable displaying recent tweets on a person's profile or by their listings/comments.

I've added a "login with meetup" option to go along with the facebook and google oauth federated sign-ins. It imports their meetup pic as avatar, their meetup interests and bio etc to the respective WSN fields. It also imports the member's twitter handle if they've supplied that to meetup. Meetup sends the person's first name usually as the only name identifier, so there will be a lot of name colissions causing WSN to append random numbers to the end of the names to make them unique. And unfortunately, meetup does not allow requesting the member email address. The member is logged in, but next time they try to edit their profile (and before they get any notifications) they'll have to enter their email if email is a required field on your site.

Non-mobile fixes in both 10.2 and 10.3 included a fuller proper fix to bulk add URLs, the member personal link list (which was redirecting to the index since who knows when), a tiny little map pin apostrophe encoding issue, a...

Read Full Blog Entry


By on Dec 20, 2018 at 12:03 AM

On a phone, your worst enemy is user input that happens to be slightly longer than you expect. The pages you check look fine, but then along comes the submitter who has a really long URL for their listing and suddenly the display of that URL on the listing details page is causing a horizontal scroll on people's phones. Today I've addressed that problem by adding the following lines to the base.css/bootstrapbase.css to be applied only on small screens:

.detailedinfo { display: inline-block; word-break: break-word; }
.urlarea .thumbshot { float: none; }

That forces long URLs shown on the details page to wrap onto multiple lines even though they have no spaces -- hopefully that inline-block doesn't have unintended sideeffects on other elements, I didn't see any. And the other line makes the URL start below the thumbshot instead of next to it, so it has more space to fill out.

Relatedly, I found that listings with very long titles (even with spaces) were causing their categories to become potentially wider than the screen. This proved a much more frustrating problem. It's easy to solve if you remove the tables and use a div only layout, but I can't assume that everyone will want to do that so I had to wrestle with the oddities of table layout CSS. In the end, based on a stackoverflow suggestion, I came up with this nonsensical voodoo that somehow works:

td.link
{
max-width: 0; /* I know it makes no sense, but it works, and removing it breaks */
}

.panel-title
{
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
}

The .link panels continue to have a greater than zero width in defiance of all logic. Notably, if i apply the CSS to .panel instead of .link then logic does semi-apply to all other panels except the .link ones and they shrink to at least near nothing. Presumably it's something about being a <td> element that makes logic not apply at all. Thus if you happen to be using a tableless div layout with class="link" I almost...

Read Full Blog Entry


By on Dec 19, 2018 at 3:02 AM

One of the big annoyances I run into during WSN installations is cookie conflicts. If you only have one installation per domain you never have to worry about this, but I've often got dozens. There's nothing more frustrating than running the setup and then not being able to login to the admin panel because some other installation used the same cookie names from who knows what path, perhaps a global cookie from some other subdomain even. Digging through Chrome settings to remove the cookie to get in to change the cookie names is no fun.

Some time ago, I added a section to setup.php which checks to see if the installation is in a subdirectory of another WSN installation. When it detects that scenario, it automatically sets unique login cookie names. And that helps one common scenario... but it does nothing for all the other places cookies can come from.

To solve this, my first thought was to make setup.php check for $_COOKIE['wsnuser']. But then I realized that would only work for a manual setup (which almost nobody does anymore), because autosetup.php loads setup.php in a programatic way that does not transmit your browser cookies. So what I ended up having to do is modify both setup.php AND autosetup.php, so that autosetup.php can do the cookie check and can then send the request for de-conflicted cookie names to setup.php as a url parameter which setup.php then obeys.

The end result? No further risk of being immediately unable to log in to a fresh installation. There is still a risk of cookie conflicts though: you might have another installation capable of setting a conflicting login cookie, but which you are not presently logged into in that browser, but which will create a problem when you login later. I'm not sure if there's anything I can do to automatically handle that scenario.

If you encounter such a problem, by the way, you can solve it using a tweaks.php file.
<< April 2019 >>
SunMonTueWedThuFriSat
123456
78910111213
14151617181920
21222324252627
282930

Recent Comments