Webmastersite.net

Search    Register    Log In   


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.


By on Dec 14, 2018 at 2:12 PM

Due mainly to 16 years of legacy, WSN uses tables as the default way to arrange your category and listings layouts. This has the advantage of making it easy to control the number of columns per row (via the settings at Admin -> Settings -> General), but the disadvantages of being considered poor practice and not reflowing easily on mobile devices.

To address the mobile problem, a year or two ago I added mobile override options on the mobile settings page. This allowed you to have for example 3 columns of categories on desktops/laptops but 1 column on mobile devices to fit into small screens without horizontal scrolling. Until now, only WSN Links had this set up by default on new installs -- today I've set all scripts to have 1 column per row on mobile by default, and have applied it to upgraders too (unless another value has been manually set or there are 0 columns per row) since there's really only one reason for another value.

That one reason was the big issue I had to deal with today: tableless layouts. For many years, WSN has allowed you to set the columns per row to 0 in order to stop WSN from auto-inserting any table cell code, so that you can remove the tables from your templates and use a div layout (autowrapping div floats or whatever you like). This created a sort of hidden conflict with the mobile override, because you might set the category columns per row to 0 at Admin -> Settings -> General -- but if there were a mobile override value of 1, you wouldn't realize you had to change that to 0 too. What I've done is I've made WSN automatically change the mobile override column values to 0 when you change the non-mobile values to 0, and change the mobile override column values to 1 when you change the non-mobile values from 0 to another number (reinstating tables).

This should allow a seemless experience where sites will fit mobile screens by default without your having to fiddle, and you'll still be able to change to a tableless layout with...

Read Full Blog Entry


By on Dec 13, 2018 at 11:12 PM

Someone today found the indent -s in the category level selectors confusingly unexpected. On consideration, the indent only makes sense for non-level selectors. Thus I've added a separate option for level selector option html compared to non-level selector option html, and have removed {CATINDENT} from the level selector one. I've also removed the category selector denied permission option html setting, which was using optgroups for MSIE7 support... it makes more sense these days to simply automatically apply the disabled attribute to the options since all browsers since MSIE8 support it. Although it looks like the current behavior is to just not show what can't be used, anyway.

I've also been running into several people who feel that WSN Links is broken because they've activated the show links in frameset switch. This switch worked fine back in the day, but with most modern websites being HTTPS and most modern web browsers being increasingly strict about security, it seems that browsers will refuse to render many sites in a frameset due to security policies on mixed content. To dissuade people from thoughtlessly using the switch, I've just moved it to the advanced options page.

Came upon a series of geolocation problems earlier this week. First there was an error that was making sites appear dead to unregistered guests when facebook connect was enabled but the new version of maxmind geolocation wasn't downloaded yet. Then there was a corrupted maxmind database download on one of my sites that was taking the site offline (a problem which is likely more frequent now because the new maxmind files are about 50 MB instead of 10 MB) -- I've fixed that by making it delete the file when the database can't be read.

My next major task will be an overhaul of the calendar system to add location and mapping and RSVP caps to events. This will probably lead to a new script WSN Group which will be optimized for group collaboration and meetups. I'm also giving thought to sta...

Read Full Blog Entry


By on Dec 09, 2018 at 9:24 PM (Edited Dec 09, 2018 at 10:34 PM)

Today, I've been working mostly on updating the WSN KB blog theme. That's the theme this blog is based on.

The main change I wanted to make was to add a simple subscription button. It's much better for a blog to have a button to click on the front page for members to subscribe to email notifications of all new blog entries, instead of expecting people to edit their profile and set "Notify of all new blogs" to "yes". To do this I had to change the backend to make it possible to subscribe with a click. And then it seemed like a good idea to have the button available to guests too, by making it take them to a registration page configured to automatically subscribe them when they complete their registration. And an unsubscribe button seemed like a good idea. The end result of all this was the following template code which you can use in any WSN script as of 10.3.20 Beta 3:
<IF {THISMEMBERISREGISTERED} and {THISMEMBERNOTIFYOFLINKS} is yes>
<div class="addnewblog"><a href="index.php?action=unsubscribelistings" class="btn btn-info btn-lg"><span class="glyphicon glyphicon-remove" aria-hidden="true"></span> {LANG_GENERAL_UNSUBSCRIBEEMAIL}</a></div>
<ELSE>
<div class="addnewblog"><a href="index.php?action=subscribelistings" class="btn btn-info btn-lg"><span class="glyphicon glyphicon-cloud-download" aria-hidden="true"></span> {LANG_GENERAL_SUBSCRIBEEMAIL}</a></div>
</IF>

I noticed the blog theme, and so presumably other upgraded old themes as well, had a repeating pattern of magnifying glasses in the search input background due to the CSS rule #searchbox input { background-image: url('../images_blog/search.png'); } in the stylesheet. I think that was originally meant to be just shown on the left side of the input once and the base.css rule that made it only appear once must've been removed at some point after the idea was dropped f...

Read Full Blog Entry

<< May 2019 >>
SunMonTueWedThuFriSat
1234
567891011
12131415161718
19202122232425
262728293031

Recent Comments