“Every church should have Wi-Fi, says Andrew Lloyd Webber”
![By Tracey Nolan from Toronto, Canada (Andrew Lloyd Webber - Colour) [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons](https://blog.2020media.com/wp-content/uploads/2015/01/AndrewLloydWebber1.jpg)
This would make churches a more integral part of the community, he says.
It’s caught the imagination of the Twitter flock too:
How do Churches go about offering Wi-Fi in a safe and responsible way?
The managed Wi-Fi hotspot service from 2020Media offers a solution that provides value for money and internet safety.
Key Features
- Enterprise principles applied to a small business priced package.
- Cloud Managed so no expensive on-site visits are necessary.
- Capture user logon details to provide compliance with UK legislation.
- Hotspot page fully brandable.
- Firewall and Traffic Management built-in with local network isolation.
- Block inappropriate websites at no extra cost.
2020Media has years of experience offering SME internet solutions and has worked with non-profits to get the best possible value for their constituents.
Call us to arrange a no obligation demo, or to find out more about what we can offer. Tel: 0370 321 2020
Other Benefits of Managed Wi-Fi
WiFi with Facebook Login
- Build Loyalty
Guests can post a story to their News Feed, showing their friends they visited your location and promoting your organization by virtual word-of-mouth. - WiFi with Facebook Login
Deep integration between the Wi-Fi hotspot and Facebook lets your customers connect to WiFi by checking in on Facebook, using your organization’s Facebook Page as a splash page.
WiFi with Facebook Login gives organizations access to aggregate and anonymous demographic data Facebook provides about visitors.
Location Analytics
- Use the cloud control panel to compare visitor trends between sites or after launching campaigns, and to find the effect of actions on visitor dwell time or repeat visit frequency. Customize the display to show data for a specific day, weekend, or even trends over a month.
Contact 2020Media to find out more
Call us to arrange a no obligation demo, or to find out more about what 2020Media can offer. Tel: 0370 321 2020
Of particular interest to me, was the revelation that Joomla is so dependent on menus that if you create articles that aren’t linked in menus (I tend to link only the top level of a site to the main menu, and then link within articles to other articles), Joomla really doesn’t like this and you will see in the url that it’s created a baffling structure of sub-categories. If however every article belongs in a menu, then this does not happen and you can control your url structure. The menu does not need to be shown – it can be inactive.
http://www.bbc.com/news/technology-29846539
Mark Stockley, an analyst at security firm Sophos, said the warning was “shocking”. “Many site owners will never have received the announcement and many that did will have been asleep,” he said. “What Drupal badly needs but doesn’t have is an automatic updater that rolls out security updates by default.” There is strong feeling on both sides with many arguing against “dumbing down” Drupal.
Whilst we wait for an auto-update mechanism in Drupal (perhaps in Drupal 8?), we’ve always been able to update Drupal for our customers. It’s a free service but one done “on request”.
We do not apply updates automatically to any and all Drupal sites we host for a very good reason. The risk of breaking a customer’s site is too great. It’s worth noting the Drupalgeddon security problem was the first such in 9 years. So it’s arguable the risk of such a security problem happening again on such a scale is manageably small. Drupal updates typically replace the entire Drupal codebase, leaving just the /sites/ folder untouched. If a customer or their developer has made any changes to a core file, these changes will be wiped out.
Sometimes a bug will be fixed or a feature changed as a result of an update. The site may well have a work around in place already for the bug and the update will then cause the site to break. These are just a few of the reasons.
The problem for us is, we did not build the site in the first place, nor are we familiar with it’s inner workings. So for us to be sure the site is in a working state after an update is very hard to do. A working homepage does not signify the site is 100% working. If the customer is going to be involved, which in our view they have to be, to check the site after the update, they should be involved all the way through – from the point of getting a Drupal notification email of an update, or getting a notification from the Drupal security list through to the timing of the update, to checking the site afterwards in case a roll back is required.
What changes have we made? Actually very little. We have simply streamlined our internal processes to make the technical side of doing the update a lot quicker. A lot of our customers have several sites with us. So we are now using some simply scripting so we can update all a customers sites, once they give us the go ahead.
Inspiration for the scripting came from Dane Powell ‘s blog: http://danepowell.com/node/69
Our version of the script is:
Update Multiple Drupal Sites Script
#!/usr/bin/env bash
installpath[1]=/our/pathtosite1
installpath[2]=/our/pathtosite2
installpath[3]=/our/pathtosite3
for index in 1 2 3
do
filepath=${installpath[index]}
printf "Updating %s\n" "$filepath"
cd $filepath
drush pm-refresh
drush archive-dump --overwrite --destination=/pathforbackups/backup.tar
yes | cp .htaccess ../
drush vset --always-set maintenance_mode 1
drush cache-clear all
drush up drupal --yes
drush vset --always-set maintenance_mode 0
drush cache-clear all
yes | cp ../.htaccess ./
chown -R apache:apache ./
done
Notes on the script.
This script is for discrete Drupal sites, not Drupal multisite.
We copy .htaccess out of the way and put it back afterwards and we noticed Drupal updates sometimes overwrote the original.
The final steps resets the file ownership permissions on the site to whatever your webserver runs as. If using suphp this would need to be changed.
Output is written to the command line so you can see what is going on.
Use at your own risk. Comments and improvements are welcome.