Search    Register    Log In   

By on Nov 04, 2015 at 4:54 AM (Edited Nov 04, 2015 at 4:56 AM)

For many years, WSN has been using an open source flash script called OSFLV for embedding uploaded videos. This required activating the "convert videos to flv" switch and ensuring that ffmpeg was installed on your web server, which wasn't always possible in shared hosting environments and could be a pain on unmanaged dedicated servers. Also, more importantly, it meant your mobile users couldn't watch the videos because mobile devices don't usually support Flash.

Recently I found that OSFLV was no longer working correctly -- the osplayer.swf player wasn't showing up. I looked for documentation and discovered that the OSFLV script is no longer developed and the online materials for it have been taken down. Since it's dangerous to continue relying on a component that's abandoned (it could develop security holes), I set out to find a replacement video player component.

In the end, I settled on Flow Player. It has good documentation, is easy to integrate, and has the popularity and longevity to indicate that it'll stick around for years to come. It's integrated now in WSN 9.2.27.

A bonus from this change is that Flow Player isn't limited to flv videos -- any type of video can now be played. Under the hood, this uses the HTML 5 <video> tag. The upshot is that you no longer need ffmpeg (or youtube) in order to show uploaded videos with a listing. You also no longer need flash, which means if you upload a .mov, .mp4, .m4v or .avi file it can play on an ipad, iphone or other mobile devices that don't have Flash.

FFmpeg is still useful for autogenerating thumbnail images from videos, so the autoconversion switch will remain.

By on Oct 23, 2015 at 2:36 AM

Sorry for the downtime on some parts of the websites this week. After selling my most server-intensive site I've been downsizing from a dedicated server to shared hosting, and the process has proved more complicated than anticipated. Everything except the demos is back up now, and I'll get to the demos shortly.

In the process I found and fixed a moving-related bug with integrated sites. The uploadpath value in the database doesn't change automatically when the config.php version of that value changes, and this results in integrated scripts failing to find the themes. Run upgrade.php to fix that.

Just as a tip for anyone else moving a website, make sure you don't copy the cache directory -- those thousands of small files take forever and aren't necessary.

By on Sep 14, 2015 at 4:23 PM

Most of my clients make most of their revenue from displaying advertising. With that in mind, I've been working on a new script called WSN AdUnblocker to help increase advertising revenues.

If like many of us you use an ad blocker to browse the web, you may have noticed some sites detect that and ask you to whitelist them to allow their ads to be displayed. If you're like me, you'll give that a try and leave them whitelisted as long as their ads aren't so aggressive that they make the site hard to use.

There's no completely generic way to detect and deal with ad blocking, because every web script works a bit different. Fortunately I've been able to simplify it to the point where it's very easy for anyone using WSN's advertising system.

For any other script it'll need a way to add jquery and jquery ui if not already present, then a way to add a line to the jquery document ready function and add a div around the ad, and then a specification of what pages to expect an ad on. This is likely too complicated to expect the average webmaster to work out on their own, but it's something I can
do as an affordable service.

So far I've got options to customize the language and to choose how often to re-prompt (either every page load if you don't want to allow freeloading or every X days if you want to be gentle with an occasional prod).

By on Sep 04, 2015 at 2:18 PM

The last few days have seen several releases relating to MIME HTML emails. Here's what happened.

The first discovery was that sites which had been sending MIME messages okay before started spitting out error and not sending the mail when their web servers updated to PHP 5.5.26 or later. I investigated and found that PHP version included a change to PHP's mail function restricting what can be sent in the headers field, in an attempt to stop malicious header injections. Unforunately it stopped the MIME code of WSN and many other scripts. I rewrote all the MIME code to use simpler headers and transfered much of it to the message field.

That patch worked for me, but actually created a problem on a PHP 5.4 server which was unable to parse message field headers that used windows-style line breaks. I converted to the PHP_EOL constant and that made all PHP versions work at the same time, finally.

If you have any website which is sending MIME emails by default, please be aware that it either already has or soon will stop sending emails (when you reach PHP 5.5.26) until you update to the latest release of one of the active WSN series: 8.0, 9.0, 9.1 or 9.2.

By on Aug 26, 2015 at 3:58 PM

Went to a developers meetup last night that covered RethinkDB and Grunt.

RethinkDB is a NoSQL database with a query syntax that reminds me of jQuery, lots of chained selectors. The primary application seems to be highly reponsive real-time apps, where its push notifications provide a simpler and more scalable alternative to having to poll the database every few seconds. It might be useful for a future project but I won't be using it for WSN because of the impracticality of helping everyone to install it on their servers. Really the only components where it'd be notably better than MySQL are the chat and IM systems.

Grunt looks much more useful for my development process. It's a task automation tool with 5000 different task plugins, especially useful for the build and release process. I've already built a suite of custom automation and release tools for WSN, but I'll be incorproating Grunt into those in the future to leverage all the plugins.

By on Aug 19, 2015 at 4:31 PM

Cool discovery of the day: SQL Fiddle. Should help with quick tests.

I've been working hard on smoothing more rough edges of the bootstrap theme. That includes collapsing the menu panel at mobile sizes, styling quoted posts, and fixing up a bunch of templates. Almost ready to roll out bootstrap as a default option during setup with a choice of bootswatch color schemes. Hopefully this will prove helpful to people who don't have time to mess with the stylesheet.

By on Aug 16, 2015 at 11:14 PM

Gravatars are centrally-stored avatars used by wordpress and many other scripts. The latest WSN release ads an "autoload gravitars" switch, which finds the gravatar for anyone who doesn't upload their own avatar when registering.

If you have a lot of current avatarless members, you may want to go back and load gravatars for them to make your site and especially the comments threads a bit more colorful/personalized. To do that, copy this script to a text file and save it as loadgravatars.php:

require 'start.php';
if (!$start) $start = 0;
if (!$perpage) $perpage = 50;
$q = $db->select('all', 'memberstable', "1=1", "ORDER BY id DESC", "LIMIT $start,$perpage");
$n = $db->numrows($q);
$m = new member('row', $db->row($q));
if ($m->avatarname == '' && $m->email != '')
$filename = md5(strtolower(trim($m->email))).'.png';
$gravatarurl = "http://www.gravatar.com/avatar/".$filename;
$checkurl = $gravatarurl.'?d=404';
$test = urlheaders($checkurl);
$exists = true;
foreach($test as $t) { if (strstr($t, '404 Not Found')) $exists = false; }
if ($exists)
$m->avatarname = uploadurl($gravatarurl, $filename, false, 'avatars');
$msg .= 'Added gravatar for '.$m->profileurl().'...';
$start += $perpage;
if ($n) indirectredirect($msg." Continuing to next batch...", "loadgravatars.php?start=$start");
else die("Done!");
require 'end.php';

Upload that to your WSN installation's main directory and visit it in your web browser to start loading gravatars.

By on Jul 29, 2015 at 2:32 PM (Edited Jul 29, 2015 at 2:35 PM)

A while back, I added some automatic file extension correction code that fixed the extension for files that were named incorrectly. If somebody named a png file as my.jpg, WSN detects that it's actually a png and renames it to my.png so that thumbnails etc work correctly.

Turns out there was an unexpected problem with this. It works fine with images, but other file types have MIME values which can't easily be matched to a file extension. MP3 files can have a MIME type audio/mpeg or x-wav, so WSN was renaming them with .mpeg or .x-wav extensions. The next release of all the active series fixes this problem by restrincting the MIME renaming to only a small whitelisted selection of detected MIME types: JPEG, GIF and PNG files.

Also fixed a 9.1/9.2 bug that was causing files to download with the wrong file name.

By on Jul 17, 2015 at 6:03 AM

Big changes in WSN Gallery yesterday. Youtube has completely dropped support for RSS feeds and hasn't introduced any equivalent searching mechanism in their much more restrictive api v3. Since youtube isn't playing ball and I'm unable to find any workarounds or third parties to generate youtube feeds, I've changed the feed focus over to flickr. WSN Gallery can now take a flickr search term from the submit feed page instead of a youtube search term. Unfortunate to have to make the change, but hopefully flickr will prove useful to someone, as they seem committed to their feeds.

Suppose you wanted to make a gallery site of animal photos. All you need to do now is create a category for each animal. In the cats category, submit a feed and use the search term (actually flickr tag) "
cats" and you'll get new cats automatically appearing every day. It's that easy.

Also fixed a template issue in WSN Gallery which was causing the columns to not align properly.

By on Jul 08, 2015 at 12:14 PM (Edited Jul 08, 2015 at 4:02 PM)

A few days ago, all of my WSN installations stopped being able to update themselves. At first I thought something was wrong with the tar extraction code as it was only extracting the folder and not any of the files in it. After a few hours of testing I discovered that the problem was wider than that, and in fact any script-created directory was being created with 600 permissions which make it impossible to write any files to it. Worse yet, script-created files were also created as 600 which causes them to show up as 403 forbidden errors on the web. This included the javascriptheader.js file, so all javascript was broken, impairing functionality considerably.

My web host, Liquid Web, is oblivious to the fact that things never worked this way before and suggests setting a umask in the script. For the sake of anyone else on a web host with bad defaults (so far I've only seen it happen on liquid web), I've set a umask(022) in the latest release of the four active series. This umask value causes the default permissions to be 755 for directories and 644 for files. Since the PHP manual entry for umask warns that it's not reliable on multithreaded webservers, I've also added CHMODs after file and directory creation to be extra sure the right permissions are set in all server configurations.

Unfortunately, if you're on Liquid Web and already affected by this (not sure if it affects all their clients), you'll have to manually open includes/prestart.php and add umask(022); right after the <?php at the top in order to be able to run an automatic update. There's nothing I can do to help that, except to offer to make that change for you manually if you contact me, since it's the old version that has to download and extract the tar.
<< April 2019 >>

Recent Comments