Search    Register    Log In   

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 issu...

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:

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

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...

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.

By on Dec 18, 2018 at 7:56 PM (Edited Dec 18, 2018 at 7:58 PM)

The changes I made a couple weeks ago to the $leaveencoded and $nomemberinfo flags have had more than their share of hard to notice side effects. The latest I've found are the menu manager delete buttons not showing and the manage redirects page acting as if all switches were off when they're not. Hopefully I've caught all the recently-messed-up admin pages now.

There was also a problem with the category level selector for the add url list option, caused by having more than one level selector on the same page... I thought I'd fixed it before but apparently not fully until now. Then there was a little error message at the end of CSV exports that I fixed, which I hadn't noticed before because LibreOffice Calc automatically edits it out as being bad data. And an error on the admin stats page that was happening when there were no stats in the database yet.

I've gotten started on calendar enhancements. First, I added all the same location fields that links have to events (address, address2, city, state, country). I made the preexisting events "location" field into a location name field, since for events (unlike links) the location name is not likely to be the same as the event title. Then I ported the postal code autofill from links so it works for events. I was able to add the submit/edit map to the add/edit events pages. In imlementing an event details map, I found that there wasn't actually an event details page yet -- only a day page that showed all events for the day -- so I went ahead and added an event details template and page. Also added an event pin template to control what shows on the pin. In the future, I hope to add map on the calendar page that shows pins for where all upcoming events take place.

All the event mapping features can be toggled on or off with the "Calendar event maps" switch.
<< January 2019 >>

Recent Comments