Administración de plugins para WordPress MU. Esta es una revisión del Plugin Commander y está destinado a sustituirlo. Utiliza una  página de opciones para ajustar los permisos de plugin. Puedes activar plugins globalmente o solo para determinados blogs.

Solamente funciona con la version de WordPress mu 2.7.1 y superiores!!

Instalación

• Copia en la carpeta mu-plugins.

• Asegúrate de que el menú de plugins está habilitado en las opciones de sitio.

Descargar

• WpMU Plugin manager

El acceso a un sitio web es de las partes mas importantes en una comunidad. A veces el diseño de la zona de inicio de sesión  puede ser confuso o simplemente poco estético. Recuerda que este va a ser el primer lugar donde el usuario va interactuar con nuestra página y una zona de acceso bien diseñada le dará credibilidad a su comunidad.

Éstos son algunos de los plugins  y tutoriales que  haran de su zona de inicio de sesión de delicia a sus usuarios:

Sliding Login Panel:

» Demo y tutorial aquí.

Twitter-like Login:

» Demo y tutorial aquí

WordPress Modal Login:

Demo y tutorial aquí

Wp-mu Login areas

BM Custom Login:

» Descargar este plugin

Custom Login Plugin:

» Descargar este plugin

I just noticed that there is yet another location in the Buddy Press core where blogging functions are used and that is in the search bar type box:

Since on this platform there is only going to be the 1 blog which controlled entirely by admin then there’s no need to offer the function of searching for all blogs on the platform. To remove this code then we need to open the file; “wp-content/plugins/buddypress/bp-core/bp-core-templatetags.php” and remove the following block of code:

This bit of code simply adds the “Blogs” option to the drop down menu if the BB Blogs is installed. So deleting this code removes the option from the menu. If you prefer you can put a ‘#’ symbol to the left of “$Selection_box” which will comment this line out so its not executed but it still remains in the source code for any future use or just for reference purposes. Many programmers like to leave original code in place, which is fine. Whatever!

I rolled 2.8.5.2 out for wpmu yesterday; updates haven’t hit yet, but you should be able to snag packages from koji.  Some security and bug fixes in there.

I still need to file a ticket to get it into F12, since it’s getting a little late to make a change there.

In wordpress MU the theme editor is switched off since there’s a security flaw in its design whereby any user is able to change the current theme/template with it. This is a bit of a pain when building a new site as during testing I often want to change a tiny thing or to try something out. Having to log in via FTP, download the file, change it and re-loading it back again is rather inconvenient, making a simple 1 minute job into 5 minutes. So I looked around for a solution to get the theme-editor.php back onto the admin menu.

I discovered that what I had to do was to create a new PHP file inside the mu-plugin folder called "theme-opts.php" (for example) and fill it with the code below:

<?
add_action( ‘admin_init’, create_function(‘$pages’, ‘if(is_site_admin()) return remove_action("admin_init","disable_some_pages");’),1);
add_action( ‘_admin_menu’, create_function(‘$theme_menu’, ‘return add_theme_page( "Editor", "Editor", "edit_themes", "theme-editor.php");’ ));
add_action( ‘_admin_menu’, create_function(‘$plugin_menu’, ‘return add_submenu_page( "plugins.php", "Editor", "Editor", "edit_plugins", "plugin-editor.php");’ ));
?>

This code re-adds some of the options that are available in the single user wordpress software but is missing from the multi-user platform. It’s not really a good idea to leave these options online when the site is open to the public, but for testing/development purposes it is completely fine.

Ok, so we “did it”. Or at least, we did some of it…

Here’s what we did do in our allotted 12 hours (roughly in order…):

• bought a domain
• set up a google docs object spreadsheet
• designed a logo
• downloaded and installed WordPress MU, Drupal, Omeka
• drafted an Information Architecture
• installed WP plugins
• made a decision about platform(s)
• created blank pages based on the IA
• imported object data from Google Docs to Omeka
• wireframed and designed key templates
• built css and then WP templates
• wrote content
• wrote a simple WP/Omeka plugin
• designed a dummy floorplan
• tweaked (a lot..)
• went live with http://dev.thefuturemuseum.com/ after almost exactly 12 hours…

Technically (just to give you a reminder) we used a combination of WordPress MU for the bulk of the site and the really rather nice Omeka to hold the object data. Dan built a WordPress plugin which pulled the object data from Omeka’s alternative response formats and inserted it into our WP pages.

Prior to making the decision about which platform to use, we held our object data on Google Docs and used a simple web form to add stuff. Once we decided to use Omeka we used the CSV import plugin to get our data out of Google Docs.

Initially we were thinking we’d use Omeka on the front end too, and just re-skin it to look like the rest of our site (ie users would “silently jump” over to Omeka to look at collection items and then back again for “other” museum information. We realised pretty soon though that it’d be much better to not have essentially two sites to maintain and design so instead went for the WP front-end / embedded Omeka objects approach.

So what did we learn, and why…?

We set out with two main aims. Firstly, we wanted to show that it is possible to build (museum) websites quickly, using cheap or freely available tools and techniques. On the whole, we both feel we achieved this, managing to produce a site from scratch and get it live. This is not to say we’re 100% happy with the site we produced: both Dan and I wanted at least another couple of hours to tweak and fiddle; had we been building a museum website in a week, this would still have been the case (there is NEVER enough time, right?!) but still, 12 hours was a very, very tight timescale to set ourselves.

Clearly, many of issues raised via Twitter or on this blog remain for most “real” museums and we had a huge luxury in not having to deal with painfully slow signoff, huge stakeholder meetings, conflicting pressures and political tensions.

I guess the point we’d make in response to this is one that we have both made many times in the past: although no museum is every likely to (want to!) build a website in a day, there is a tendency for the timescales created by the political nature of museum decision-making to actively damage projects. The raw enthusiasm and energy that is created by doing things rapidly, cheaply and – frankly – without the polish of perfection – is hugely important to any project. A year-plus long timeline (some museum online projects I’ve worked on have been 3+ years in length!) will by default kill any passion and enthusiasm, and probably most of the members of the project team, too. Finding a middle ground where decisions can be made quickly and technologies like WordPress or Omeka are installed and configured easily; finding a framework where museums can play and experiment – this is clearly where success lies.

A couple of other people mentioned that the costs (currently, erm, £6.39!) are unrealistic and should include our time as well. This is probably right, depending on how you cut it, but (sadly – wish my day-rate was higher…!) this would still amount to not much more than – say – £1000 for total build.

The second thing we wanted to do was to provide some kind of genuine clarity into the process that we followed in the hope that it might help others. We hope we’ve done that to date, and intend to continue to do this into the future with various presentations, starting with a workshop at DISH 2009.

On a more practical level, we aim to take the plugin that we built, re-write it from the ground up and make it available for others to use in their WordPress installations. The Omeka approach is great – we can’t stress enough how impressed we were with the site, the documentation, the system itself – but we see that for many (perhaps larger?) institutions, a WordPress front-end coupled with an Omeka collections management backend is likely to be more flexible than a “one size fits all” approach of using Omeka to do everything. We both have some ideas which we’ll articulate later about how Omeka might be improved to help this and hope to be in touch with the Omeka team shortly.

Meanwhile, we’re going to snapshot the site we built as a showcase (possibly at a new subdomain – 12hrs.thefutureuseum.com or somesuch) and begin planning how we can take our main thefuturemuseum.com site forwards over the coming year. If you have ideas, please do get in touch!

At bleeding last we can run the install script. The script is intelligent enough to figure out its being run for the first time and runs the installer, so all you need to do is go to the URL where you installed the software; http://www.sinsearch.co.uk/wp/

If you scroll down past all this crap, it will get to all the various options.

This installation has only been tested when placed in a sub-directory, rather than in a sub-domain. Besides there is allot of discussion on the internet about sub-domains not being as valuable in terms as search engine ranking as they used to be. In my opinion having a sub-domain name or not makes little difference overall.

Open up the notepad file that contains your Database access details. For the Database Name field copy the value labelled as “DB Name”. Likewise for User name copy the value associated with “DB User” and finally copy over the password. You can safely leave the database host to its default which probably is “localhost’.

The next section refers to the Sever address. I personally just left it to its default which for me was “sinsearch.co.uk” and then we come to the “Site Details” section:

You just need to enter a site title and an email address. Ensure your email address has been setup and is working before using it as the system will use it to email your administration password to you.

Once you are satisfied that you have entered all the information correctly then click on the “Submit” button. The server setup will then go and do its thing, displaying a screen like this (but without the blacked out bits):

The bottom bit where it refers to fixing permissions we want to ignore for the moment as we need to keep the permissions as they are in order to install the other scripts properly. In the next article I’ll deal with installing “BuddyPress” and loading the relevant theme.

There are dozens of social bookmarking services.  If you tried to promote your site on all of them, you would probably end up spending more time on submitting pages to those sites than you would on producing new content.

Most of those sites are very sensitive to ’spam’, and are hostile towards people who are clearly shilling or promoting their own web sites.  So, if you have a strong community already, why not encourage your users to promote your site for you, rather than doing all the submission work yourself.

One effective way to do this is to place social bookmarking links at the bottom of each article.  These links take the user to the submission page of their favourite social bookmarking site, so all they have to do is enter a quick description, and submit.

One such script is available for download here.

This script was originally designed by Hugo Haas.  I have been using it on my web sites for quite some time, simply updating the social bookmarking links as necessary.

The script is ideal for use on any web site – whether it’s powered by WordPress-MU, Joomla, e107, or any other CMS.  It’s also useful for custom coded sites.  Just extract the folders, drop the Javascript into your pages, and you’re good to go.

Lire l’article en entier avant d’installer !
D’abord une bonne nouvelle : ça marche !
Donc ne pas paniquer, ne pas s’énerver, ne pas faire n’importe quoi.
Bien choisir tout d’abord dans quel dossier ou sous-domaine sera installée la plateforme.
Télécharger sur le site le package.
Le dézipper, ouvrir les dossiers et transférer par ftp dossiers et fichiers dans le dossier de destination, là où sera la plateforme (on a les dossiers wp_admin, wp_content et wp_include ainsi qu’une série de fichiers. Le package comporte aussi un fichier wpmu_settings.
L’installation est différente de celle de WordPress, à savoir qu’on n’édite pas à la main le fichier wp_config.
On transfère sur le site wp_config_sample et le script d’installation va créer le fichier wp_config. Il existe de plus un fichier wpmu_settings.
Il faut donc avant toute chose donner des droits d’écriture et d’exécution au dossier de destination, en un mot mettre le chmod à 777.
(si vous ne comprenez pas ces mots, vous ne pouvez sûrement pas installer une plateforme de blog chez vous… quoique)
Ensuite, il faut taper dans le navigateur la future adresse de la plateforme soit : adressewebdossierdestination/index.php.
Cela lance le script d’installation : index-install.php
Vous renseignez en ligne les paramètres : nom de la base de données, utilisateur, mot de passe, adresse sql (à la place de localhost).
Ensuite il vous faut choisir le mode d’affichage de vos futurs blogs, soit à chaque blog un sous-domaine, comme chez wordpress (ex freyafinker.wordpress.com) ou à chaque blog un dossier wordpress.com/freyafinker.
Le premier cas aurait été idéal mais cela complique les choses au niveau des paramètres DNS chez l’hébergeur, j’y ai renoncé.
Donc si tout marche bien, votre plateforme de blog est installée.
Ne vous laissez pas inquiéter si par hasard il y a un problème de redirection pour aller administrer votre plateforme. Rappelez-vous que chez WordPress, la console d’admin se trouve sous wp-admin. D’ailleurs on peut y accéder en tapant simplement l’adresse de la plateforme. L’interface ressemble à celle d’un blog wordpress avec en plus un utilitaire d’administration de vos futurs blogs.
Méfiez vous du nom du blog, évitez les caractères spéciaux.
Si ça ne marche pas, recommencer l’installation (supprimez toutes les tables de la base de données, supprimer wp-config du serveur et retournez dans index.php). Eventuellement, c’est préconisé sur des forums, essayez d’enlever htaccess, et de le remettre seulement au moment où l’installation le réclame, mais je ne crois pas que ce soit nécessaire.
Un mot sur la version française : actuellement (version 2.8) le fichier wp_config est à éditer à la main, et il manque le fichier wpmu_settings, ça craint ! Mais globalement c’est en comparant les deux versions que j’ai compris ce qui se passait.
Pour la traduction en français, je ne vois pas l’intérêt de la version francophone, car les fichiers de traductions sont présents dans le dossier POMO de wp_include dans les deux cas. Quant aux thèmes, vu qu’ils sont réduits à leur plus simple expression, il suffit sans doute d’aller chercher les thèmes francophones correspondants. On verra à l’usage.
Surtout ne lisez pas le readme, c’est incompréhensible, n’allez pas sur les forums où on vous embrouille, restez calme.
En attendant, j’y suis depuis 9h, bye.
Ah oui, pour les amis, un p’tit blog gratuit sur ma plateforme, ya qu’à demander, si si ça me fera plaisir.

suite le lendemain matin : c’est vraiment un super outil, jusqu’à quand restera-t-il gratuit ? Les développeurs ont fait un super travail, donc pas étonnant qu’ils aient envie de faire du business avec ! Beaucoup de programmes d’affiliation, de versions payantes sont proposées.
Problèmes rencontrés : taille de mémoire avec fatal error, lorsqu’on installe un thème un peu trop gourmand en espace alloué, ou lorsqu’on télécharge un médium un peu gros. On peut régler les paramètres d’espace pour chaque blog créé, choisir la taille maxi des fichiers à importer.
Les thèmes : pas étonnant qu’ils n’aient mis que les thèmes minimalistes, bien vérifier qu’ils fonctionnent avant de les proposer.
Les plugins : j’ai même pu installer Akismet l’anti-spam (gratuit tant que la plateforme ne récupère pas plus de 500€), mais il faut entrer le code API pour chaque blog. Un autre plugin m’a fait planter tout le système, je l’ai vite retiré du serveur.
La langue : ce n’est pas encore optimal, il faut comprendre un peu d’anglais pour s’en sortir !

Donc en conclusion, la plateforme WordPress MU fonctionne chez moi et c’est génial, merci WordPress, je me suis bien éclatée !

Feedback après une semaine : certains des heureux destinataires de mes blogs n’ont pas reçu d’email, et je n’arrive plus à créer de nouveaux blogs fonctionnels. Donc patience, la version 2.9 de WordPress MU est annoncée pour avant Noël. En attendant j’ai quelques blogs qui fonctionnent !

Im having a jquery conflict on my feature content glider! The glider jquery is conflicting with photosmash galleries and lightbox-pro in wordpress.mu root page.
can you help!!!!!!

This post is intended to accompany Chapter 4 of my book, the WordPress-MU 2.7 Beginner’s Guide.

If you have a WordPress or WordPress-MU powered blog, then you’ve probably noticed the dashboard.  It’s the default ‘landing page’ when you log in to your admin panel.  The dashboard provides some useful information, such as the number of posts you’ve made, the number of comments that have been approved and the number that are awaiting moderation, and even a traffic stats graph.

However, the dashboard can take a long time to load.  This isn’t a problem for everyone – if you’re blessed with a nice fast cable or DSL connection it probably isn’t an issue for you.  But not everyone has a good connection.  I’m making this post via mobile broadband because my usual connection has failed. HSDPA isn’t reliable in this area, so I’m on 3G, and even a page as clean as Google’s is taking an irritating length of time to load.

You can remove some of the clutter from the Dashboard by using the ‘Screen Options’, but you will still land on the Dashboard page when you log in to the admin panel.Personally, I don’t mind the dashboard on my main blogs, but I have some niche blogs on various community sites, and my favourite sites are the ones that blur the line between ‘community’ and ‘blog’.  When you go to manage your blog, you are dumped straight on to the Write Post page – after all, the chances are that’s why you’re visiting the admin panel of your blog.

Sending your users straight to the ‘Write Post’ page will most likely be saving them a click or two.  If it turns out they wanted to do something else, then it hasn’t cost them much time.

If you want to hide the dashboard, then one way to do so is to use the ‘Hide Dashboard‘ Plugin created by Bavotasan.  This plugin will allow you to hide the dashboard for users with certain user levels.

The default version of the plugin hides the dashboard for users who are not admin.  If you would like to hide the dashboard for everyone, you can do that with a simple edit:

Just open the plugin file, and remove the following lines of code:

if (current_user_can(‘level_10′)) {

return;

} else {

Also remove the closing ‘}’ above the ‘add_action’ line near the end of the plugin file.

For your convenience, you can download the edited version of the plugin here.

This post is designed to accompany Chapter 4 of my book, the WordPress-MU 2.7 Beginner’s Guide.

Would you like to allow users to edit their themes on your WordPress-MU blog?  One of the most common requests from users on WordPress-MU sites is the ability to edit the themes that are offered.  Giving users the ability to edit the PHP files that make up a WordPress-MU theme is a little risky, but it is possible to allow users to edit CSS files, which will give them some freedom to customize their site, and is much less risky from the site owner’s point of view.

If you want to allow your users to customize their WordPress-MU themes, the first thing you need is UserThemes Revisited.  You can download the plugin here.

Before you install the plugin, I would recommend making a few changes.  In it’s unedited state, the plugin allows your users to access both PHP and CSS files.  Offering unrestricted access to PHP files means that you are risking the possibility of malicious code being ran on your server.  Let’s block PHP files from being edited:

Open up /wp-admin/theme-editor.php – under the line that begins with $parent_file,  insert the following code:

if((get_option(‘ut_use_user_theme’) != 1) || (get_option(‘ut_enabled’) != 1))

{

wp_die(‘Either you have not been granted permission from the site administrator to access the theme editor OR you do not have a usertheme as your active theme, theme editor will die while a system theme is active.’);

}

ds_redirect_theme_editor();

Look for this line:

$allowed_files = array_merge($themes[$theme]['Stylesheet Files'], $themes[$theme]['Template Files']);

Comment it out, and insert this below:

array_merge($themes[$theme]['Stylesheet Files'],$themes[$theme]['Stylesheet Files']);

Next, open the file /wp-admin/includes/mu.php and comment out this line:

unset( $submenu['themes.php'][10] );

Now it’s safe to upload and install the UserThemes Revisited Plugin.  Your users should see a screen like this one, which allows them to create their own copy of a theme they want to edit.

Once they’ve made a copy of a theme, they can edit the CSS files using the theme editor.

For your convenience, you can download the edited versions of the core files here.

Two topics in this post, one which I should have blogged about a month ago but somehow totally forgot to!

Lincoln Christmas Market Website

I’m particularly pleased with the Lincoln Christmas Market website. Launched mid July 2009, it’s self hosted on a WordPress MU install. The idea behind it is to provide a platform to easily release information about the market as it becomes available, be very customisable for the City Council and also promote discussion and involvement. There are plans to use it to liveblog the actual market, posting pictures and video as they are taken. Hopefully I’ll post up about this when it happens as I should be involved!

I’d also like to point out that the pic in this post was taken using the Screengrab! plugin for FireFox. This is a doody little plugin that, with a single click, can take a grab of the current view of any web page, the whole page or a selected portion of the page. This saves you having to trim any unwanted junk out or stitch together a screenshot in Photoshop. Very cool and a real timesaver!

Yesterday I presented a blog workshop (WordPress MU) and tomorrow I am presenting podcasting in a district. Last week I presented a half day Introduction to Web 2.0 to media specialists. I love it when attendees find a tool that they can apply to their classroom or media center.