openedweb.com

Ibo, from the Elgg Developer Google Group, just updated my Tinymce with TinyBrowser implementation. I’d like to thank him as I have been very busy.

It implements the new version of TinyBrowser 1.40 beta. New features include:

• Multiple Folder support with ability to create, change, and delete folders.
• Action for moving files between folders
• Height and width values in the pop up window.

It also fixes a number of bugs. In addition, it allows TinyBrowser to create a full upload path.

This remains a way to upload files from within the image and media embed functions in tinymce, while we wait for the new text area embedding tool being developed for Elgg 1.5 slated for February.

The popular “free” educational blogging site Edublogs has begun inserting inline content link ads in the posts of their free blogs. Once users are logged in, they no longer appear, but anyone view the blog sees the ads.

To disable the ads, one must become an Edublogs supporter costing $25 per year. There are other benefits such as more server space and Twitter integration. Alternatively, schools can set up Campus subscriptions starting at $900 per year for 100 blogs.

On the popular Classroom 2.0 site, teachers are registering shock and dismay at this unannounced development, saying that they feel “bamboozled.” Concern has been expressed about control over the content of these ads. Teachers and students have invested much into this blog platform and suddenly find the landscape has changed.

In fairness to Edublogs, the potential for advertising has been in their terms of service for some time–I looked into it many months ago. (You DO read the TOS before clicking I accept, don’t you?). In this tightening economy, the flow of easy captial has been shut off. The free hosted social applications need to pay their bills to keep their servers up and running and to pay staff.

I have always expressed concern about hosted Web 2.0 solutions for these very reasons. There is also the issue of data ownership. If one of these companies goes belly up overnight as has been the case with so many major corporations of late, what happens to your data?

The solution is free and open source software on either rented web server space, or on in-house servers. No, these are not “free” solutions, but they are inexpensive. Webhosting accounts can be had for as little as $5 a month and most offer ample resources for hosting your own Web 2.0 solutions. Furthermore, you will not find yourself blindsided by changes in policies and terms.

There are many options for software. Multiple blogs can be hosted on WordPressMU, Social Networks on Elgg, and the list goes on.

Stay tuned for more such developments and start studying up on free and open source Web 2.0 applications. As has been said so many times before: there is no such thing as a free lunch!

This is one of the most frequently unanswered questions with Elgg users. I’ve seen it numerous times in the various Elgg support venues, and I have been asked many times.

The short answer is that within the Elgg user and administrative interfaces, there is no way. If I am wrong, please correct me. The only approach that I have found is to delete it in the database. Access phpMyAdmin through your cpanel or whatever other way you may have to access your database.

Find elgggroup_entity and select the browse button.

Select the red X to delete the group. That’s it, the group is gone from the user interface. I honestly don’t know if remnants remain in other tables. Hopefully the garbage collector will deal with that.

This is the only answer that I have found. If someone has a better solution, let me know. Hopefully, over time, this will be built into the interface.

Since I work in a k12 environment, I needed to make a plugin that removed “Public” as an option when users post content. I didn’t take me long to locate the file engine/lib/access.php as the file that controls these functions.

I hacked the core code and indeed it functioned as I wanted it to. Hacks to the core are undesireable because it complicates upgrading, so I wanted to create an override. I worked many hours trying to create a hack of the core access.php, but I was unsuccessful. I just couldn’t figure out how to write a start.php that would function. Finally, I had a break through, but it had nothing to do with overriding engine/lib/access.php.

Diego Andrés Ramírez Aragón and Jens von der Heydt suggested that the key to this may reside in the views directory. I knew how to write an override of elgg views. First I created the initial directories for the plugin:

nopublic/
nopublic/views

To find the rest of the pathway, I had to find where the access file was in the views directory and mirror it. Since it was in

views/default/input/access.php

I created

nopublic/views/default/input/

Next I opened created a copy of the original access.php, made my hacks and inserted it plugins’s input folder.

$class = $vars['class'];
if (!$class) $class = “input-access”;

if (!is_array($vars['options']))
{
$vars['options'] = array();
$vars['options'] = get_write_access_array();
}

if (is_array($vars['options']) && sizeof($vars['options']) > 0) {

?>

was changed to:

$class = $vars['class'];
if (!$class) $class = “input-access”;

if (!is_array($vars['options']))
{
$vars['options'] = array();
$vars['options'] = get_write_access_array();
unset($vars['options'][2]);
}

if (is_array($vars['options']) && sizeof($vars['options']) > 0) {

?>

The start.php requires no hooks. Simply initialize and register the plugin:

<?php
function nopublic_init() {

}

register_elgg_event_handler(’init’,’system’,’nopublic_init’);
?>

I put that in my plugin directory, along with an manifest.xml file so now I had:

nopublic/start.php
nopublic/manifest.xml
nopublic/views/default/input/access.php

That disables the public access option–the basic nopublic plugin. There are many directories in the views folder that can be overridden this easily.

Clearly, there is much to explore with views overrides. I look forward to learning more about the manifestations of each file. They provide important customization options beyond themes.

I’d like to hear how others are using views overrides!

Many people have asked how to change the ways things are worded on their Elgg sites. For example, where the word friends appears, the word colleagues may be more appropriate. This is easily achieved by editing the languages/en.php file (In the case of English). The problem is that this is editing the core. If you are careless about your upgrade, all your customizations disappear. This is best achieved using an override.

The languageoverride plugin allows you to edit the file using a plugin, leaving the core intact. Simply download and unpack the plugin, then upload it to the mod folder. Now you can customize mod/languageoverride/languages/en.php to achieve the same thing. Of course, the customizations can be made before uploading.

Open the en.php file in a text editor. You will see a well commented, tidily organized file:

Click to enlarge

Find the text you want to change by browsing the appropriate headings of by using the find function.

Lets take a closer look at the friends section of the code.

Click to enlarge

If you look at the left side of the arrow, you will see the code that calls for a string of text to display. The text actually displayed to the user is on the right side of the arrow. For example:

‘friends:yours’ => “Your friends”,

The code ‘friends:yours’ displays Your friends. If you want it to display Your colleague, you would change the line to:

‘friends:yours’ => “Your colleague”,

Note that the text to the left of the arrow remains the same.

Sometimes you may see a %s sign in the message. This is a call to a variable.

‘friends:add:successful’ => “You have successfully added %s as a friend.”,

Had you just added “John” as a friend, the text displayed would be: You have successfully added John as a friend. Do not remove the %s! For our colleague example it would be changed to:

‘friends:add:successful’ => “You have successfully added %s as a colleague.”,

Once you have made the changes, save the file. Provided the plugin is activated, the new terms will display.

You do not necessarily have to use this plugin to achieve the changes. You could put a languages file in any number of existing plugins including themes. Merely create a language folder for the plugin and put the en.php file in the languages folder:

myplugin/languages/en.php

Make you changes to the en.php as you would with the plugin.

Some text may not reside in the languages/en.php folder. In some cases plugins have their own languages/en.php files extending the core. In that case, it is appropriate to edit the languages/en.php file for the individual plugin. I am not sure if there is a way to override the plugin’s language file. When upgrading a mod, be sure to save copies of any changes to language/en.php.

While this is a fairly simple plugin, I’m sure that many will find it useful. Download the file here.

Read the comments for more good information!

By request, I have written another access plugin. This one eliminates the “private” and “logged in users” options leaving only “public.”

That’s all it does. Not much else to say but download here.

I have had several requests for the Higherwalls plugin with out the walled garden functionality. I decided to make the plugin with two flavors.

The original version also overrode the owner’s block so that the links to create RSS and OpenDD feeds were deleted. I created another version that retains the ability to click on the links to get the feeds.

Again, to totally disable the feeds, you will need to go to your elgg/views folder and delete the rss and opendd folders.

I plan on using Elgg in a K12 environment, particularly my fifth graders. In order to do this in a manner that complies with our school policies and culture, I had to make some changes. Since the Elgg environment is unmoderated, I had to remove all public access to content.

Elgg’s “Walled Garden” does part of the job in that it disables public registration, but any content that users created had the option of public access which would be visible to individuals not logged in.

I created a plugin with a view override that removes this option. Now users have the choice of private or logged in users (along with any friends’ collections) when setting the access to content.

Still, access to the site could be had by RSS feeds and OpenDD. I’m not sure how big an issue this is, but I’d like to be able to do it. Dave Tosh suggested, I created an override of owners’ block eliminating those options. I believe access to these can be had unless I delete the rss and opendd views from the core. That will work, but I wonder if I could create an override of those views that disables them. I plan on looking into this.

I combined my initial plugin, with Marcus Povey’s “Walled Garden.” With “Higher Walls,” not only is registration disabled, but so is public access. Links to RSS and OpenDD feeds are also disabled.

Another issue remains. If access to content is restricted to logged in users, then the Latest Activity on the default main page will remain as a header with nothing below it. I used Customindex plugin to change the mainpage to a login page by pasting:

$form_body = “<p><label>” . elgg_echo(’username’) . “<br />” . elgg_view(’input/text’, array(’internalname’ => ‘username’, ‘class’ => ‘login-textarea’)) . “</label><br />”;
$form_body .= “<label>” . elgg_echo(’password’) . “<br />” . elgg_view(’input/password’, array(’internalname’ => ‘password’, ‘class’ => ‘login-textarea’)) . “</label><br />”;
$form_body .= elgg_view(’input/submit’, array(’value’ => elgg_echo(’login’))) . “</p>”;
$form_body .= “<p>” . elgg_echo(”) . “</a>  <a href=\”". $vars['url'] .”account/forgotten_password.php\”>” . elgg_echo(’user:password:lost’) . “</a></p>”;
echo elgg_view(’input/form’, array(’body’ => $form_body, ‘action’ => “”. $vars['url'] .”action/login”));

into customindex/views/default/customindex/content.php.

Further modifications could be done on the custom index, but this certainly serves the purpose. It is comparable to what one would encounter in a password protected WordPressMU blog.

Now I am convinced that Elgg can be modified to work within the K12 environment. Higher Walls and removing rss and opendd views directories restricts access to the community very effectively. A better solution would disabling rss and opendd through the plugin rather than deleting core files.

Now that these matters appear worked out, I plan to focus more on Elgg in terms of pedagogy. Nonetheless, I will tweak “Higher Walls” over time.

Download

Thanks to:

• Marcus Povey
• Boris Glumpler
• Jens von der Heydt
• Diego Andrés Ramírez Aragón

Jonathan Rico of Peesco.com released a Google Gadgets widget for Elgg called xgadget. Google Gadgets are snippets of code that can be inserted into widgets to present a wide variety of content. They deliver weather forecasts, rss feeds, games, videos, and more–ranging from the practical to frivolous.

Once xgadgets is installed, it appears in the widget gallery in the profile and dashboard. To get started, you need to find some suitable gadgets by going to Google’s gadget directory.

There are thousands of gadgets to choose from. Once you find a suitable gadget, click the “Add to your Webpage” button. Depending on the gadget selected, you will presented with some configuration options.

Once you have it configured as desired. click “Get the Code.” Copy the code to your clipboard and return to Elgg. If you haven’t set up your gadget widget by dragging it from the Widget Menu to one of the cloumns do so now.

(Note that you can also click on the Additional tools gadgets which brings you to Lab Pixies). Click the edit button on the upper right hand corner.

Name your Gadget in the top field, paste the Code into the code field, and adjust the height as needed (try 10-15 px more than your gadget’s size). Next set the access and click save.

You may have configuration options with your gadget. In this case, you would click edit and type in your zip code for a local weather forecast.

This is a great little plugin that makes thousands of widgets available to both the dashboard and profile in Elgg. It helps them function more like a Pageflakes or Netvibes portal. This is a great addition to the growing collection of Elgg plugins.

Jeremey Ronnel from Elbee just released an autosubscribegroup plugin. This plugin automatically subscribes new users to a group or groups designated by tha administrator.

Installation is simple. FTP the unzipped folder to the mod directory of your Elgg installation, then activate it through Tolls Administration. Next click on more information.

A field appears for entering group ID numbers. You may enter as many as you like separating the numbers with a comma. Here’s where to find a group’s ID. Go to the group page in your site and look at the url in the address bar.

The group ID number appears after the word groups in the url. Type in the desired group numbers and click save. Now all new users will be subscribe automatically to the desired group or groups.

This plugin provides much sought after functionality. Many have asked for the ability to autosubscribe new members to groups of common interest to all members. It also helps give users unfamiliar with Elgg a starting point.

If you used Subversion to install Elgg using SSH, upgrading to Elgg 1.1 stable is a snap. Simply log in and:

cd yourelggdirectory

svn sw https://code.elgg.org/elgg/releases/core/elgg1.1/ .

Make sure you include the space and period. Press enter, then agree to accept the security certificate typing t for temporarily or p for permanently. The files will scroll quickly as they are transferred from server to server.

When the transfer is done, open your browser and go to yourelggdirectory.upgrade.php

You should get a message saying the database has been upgraded and land on the login page. Log in and check your version. It should say 1.1 Stable.

Always have a backup of both the files and the database in case something goes wrong. I have done this svn upgrade with the original 1.0 release, and the 1.1 RC1 from the trunk. Note that older themes may exhibit minor quirks.

That’s it. It only takes a minute or two.

More information about Elgg and SVN

Just yesterday, the Elgg developers committed Elgg 1.1 RC1. This morning, Elgg 1.1 became an official release–in record time, I’d say. The release is available zipped up at elgg.org. It can also be obtained from their Subversion Repository:

• Core Only https://code.elgg.org/elgg/releases/core/elgg1.1/
• Full Package with core extensions https://code.elgg.org/elgg/releases/full/elgg1.1/

The following posts describe several of the new features in Elgg 1.1

• Elgg devs increase speed and reduce clutter
• New Elgg Admin features appear in SVN
• Elgg 1.09 in SVN

Kudos to the developers for their release offer more features, greater stability and speed. Now we begin the march to Elgg 1.5 in February!