Saturday, October 20, 2012

EE Multi-Language Sites (revisited) - part 2

Previously we cleaned-up the URLs, now we make them dynamic

We’ll presume the native language, English, is the root language, with Spanish and Russian as alternative languages. 

In this example, the web root is at /var/www/.


1) Create directories for the languages using their ISO name and copy the EE index.php from the root into each of the language directories

/var/www/ru for Russian
/var/www/es for Spanish

2) Edit the index.php file in the root directory. In the CUSTOM CONFIG VALUES section, add this:

//Set default language

3) Edit the index.php in each language subdirectory (ru, es), adding an extra period to the SYSTEM PATH variable, so that:

$system_path '.system'

in the /ru/ directory becomes:

$system_path '..system'

4) In the CUSTOM CONFIG VALUES section, add this and extend the URL to redirect through the current language directory. EG, in the Russian /ru/ directory:

//Set default language

Do this for each of the languages.

5) Finally, add a custom .htaccess to each of the language directories, to handle removing index.php from each subsection. Again, for the Russian /ru/ directory:

RewriteEngine on
^(.*)$ /ru/index.php/$1 [L] 

Do this for each of the languages, and that’s basically it.

On logging back into the Control Panel, you’ll be greeted with a notice:

One or more core files have been altered:

Accept the changes and get on with your life. Next we set up the multi-language variables…

Posted by admin on 10/20 at 07:48 AM
Posted in:
(0) TrackbacksPermalink

Friday, October 19, 2012

EE Multi-Language Sites (revisited) - part 1

A while ago I did a how-to on putting a multi-language site together for EE 1.x using the Multisite Module from PutYourLightsOn. It’s a good module and Ben’s support has been excellent, but for EE 2.0, I’ve found a way to roll my own…

I’ll do this in series of posts, but let’s dive in first with setup. The plan is to:

  • Clean up the URLs to remove index.php from it

  • Set up the system so the title is the filename

  • Set-up system variables so language is selected by resolving the path

  • So if the path is I’ll get the default language (English). If its I’ll get the other language translation - the plan is to have Spanish and Russian languages. Them’s the rules…

    We’re going to presume a few things:

  • UNIX-based hosting

  • Apache 2.x or later with mod_rewrite installed and enabled

  • ExpressionEngine 2.2 or later

  • 1) we create a .htaccess file in the docroot of your website. This is based on the example:

    <IfModule mod_rewrite.c>
    RewriteEngine On
    # Removes index.php
    RewriteCond $!\.(gif|jpe?g|png)$ [NC]
    ^(.*)$ /index.php/$1 [L]
    # If 404s, "No Input File" or every URL returns the same thing
            # make it /index.php?/$1 above (add the question mark)

    2) In the Control Panel (Admin > GENERAL CONFIGURATION) set the name of the site’s index page to blank (empty the field) and Submit.

    3) Test. Test the site’s links to see that index.php isn’t required in the url. A good practice is to use a template set-up through the Pages module with a fixed url (/blog/ for instance) and then see if the page can be reached.

    Some common problems include links returning 404s, a “No Input File Specified” error, or all links returning the same content. This can often be the case with hosts that require you to force query strings. If this happens, try adding a question mark as described in the .htaccess comments above.

    Other common errors, often also generating a 403 Forbidden, is the setup for Apache and whether it allows .htaccess the rights to rewrite the URL. Check your Apache configuration for the Directory command. Compare it to the example below:

    <Directory "/var/www/siteroot/">
    Options Indexes MultiViews Includes
        Options FollowSymLinks
        AllowOverride All
        Order allow
        Allow from all

    Two very important lines to watch for:

    Options FollowSymLinks   (usually missing)
    AllowOverride All       (often set wrongly to NONE)

    Mac local configurations suffer from this by default - this is why 403s occur when you try to crawl your Sites folder.

    Once resolved, your URLs should be cruft-free.  Move on now to making your paths dynamic...

    Posted by admin on 10/19 at 01:22 AM
    Posted in:
    (0) TrackbacksPermalink

    Monday, October 15, 2012

    10 steps to securing your Wordpress install…

    Using Wordpress? According to Forbes, one out of every 6 websites on the Internet is powered by WordPress (nearly 60 million in all), with 100,000 more popping up each day, and currently hosts over 56 million of those blogs. The odds are likely that you’re expecting the site hosting service to take care of your security issues. If so, the real odds aren’t in your favor.

    I routinely upgrade companies who have outgrown Wordpress or have been hacked (to my preferred platform, ExpressionEngine, just so you’re aware of my biases). I really don’t like shifting platforms just because you’ve been hacked, but quite often people and companies take a view that “software is just a solution” without realising that no solution is ever permanent - everything needs to be minded and maintained. Because the promise was “a solution”, the promise seems to have been broken and it poisons any future relationship the software has with the customer. Chalk it up to managing expectations, but for many, many people the promise is often more important than the delivery.

    So it’s amazing to discover how many sites don’t even make an effort to do the basics. Tighten permissions, move and rename known resources, mask dangerous accounts. I do think we rely too much on hosting companies, and many of those 58 million affected by those Wordpress and GoDaddy outages might agree, but there is no two ways about it: You need to secure your Wordpress environment, so here are 10 steps to making your installation as secure as possible. (Admittedly the last step has 21 bullet points, but at least it’s thorough…) Let’s keep the script kiddies at bay.


    Posted by admin on 10/15 at 09:55 AM
    Posted in:
    (0) TrackbacksPermalink

    Wednesday, March 07, 2012

    Wordpress - It’s a Victim *and* an Enabler too!

    My timing was excellent about my last post. Less than a week after I wrote about WordPress’s sloppy security, there’s news of a malware injector that invades WordPress sites and used them to infect site visitors.

    From The Verge

    A piece of malware that masquerades as antivirus software has been found on 200,000 web pages or almost 30,000 unique sites, says computer security group Websense. The exploit, which mostly affects sites built with WordPress, places a short piece of injected code at the bottom of a page…When a user loads the page, they’re redirected to a page in the top-level domain that mimics a Windows security scan, then asks them to download a malicious program to supposedly clear viruses from their computer. It’s a scam that’s been running in various forms for years, and Websense says it’s been tracking this particular threat for several months.

    They’ve got some info on the header and such - if you use that system it’s worth looking at.

    PS: We’re on Expression Engine. You’re safe.

    Via The Verge...

    Posted by admin on 03/07 at 06:58 PM
    Posted in: Gadgetry   IT notes  
    (0) TrackbacksPermalink

    Friday, March 02, 2012

    WordPress: A Cautionary Tale

    “For those who don’t quite understand the title; Automattic is the company behind the world’s favourite blogging engine – WordPress, and EllisLab are creators of fine products such as CodeIgniter – and, the commercial CMS ExpressionEngine. Now that you have the basics, the title will make sense later.” - from a blog post at By Bjorn of his business experience with WordPress. Which, for me, rang a lot of bells.

    It appears some larger companies have been cold-called with promises to pull them into the WordPress network, and some Ellis Labs customers (Expression Engine and CodeIgniter clients) have been the recipients. Which makes Wordpress tempting…Sure - the software is free, but the corporate hosting costs and support contracts can be eye-watering. Expression Engine has a nominal up-front cost ($300 for a company license) and free support - the opposite of WP. But because WP appeals to the instinct of getting something for nothing, it’s gaining traction more quickly than any other CMS. 

    The big trick, it seems, is get the foot in the door, get the software on the customer’s iron and then “blog the hell out of it”. Then they’re hooked into a service system once they realize their business depends on it (and that they’ve outsourced their control). Seriously, “self-hosted starting at $15,000 a year” is never the price - it’s the starting point - and it’ll be far more expensive. Having worked for the #1 and #2 online newspapers in the Netherlands, I’ve experienced this “bait-and-switch” first hand, and I’ve seen many people lose their jobs because of presumed promises. 

    In a previous work life, in a now-defunct company (an arm of a publish group that was once the defacto leader) we went through the same cycle. It was a classic example of a top-heavy corporate collapse…too many cooks, not enough ingredients…and for the most part fueled by the move to WordPress.

    We used a several products, all tuned to the project needs. We started migrating out of an existing, aging standard (if you want a hint, thing 10 minus 4, separated) and started moving to a new, more flexible and powerful platform. Were re-directed and railroaded into using WP via a political choice (eg, it’s wasn’t a technical choice). Development - which required huge customization of the WP software, took months longer than expected. Of course the technical arm was blamed because Corporate were sold something else.

    Corporate Project Managers decided to bring in external developers with specific experience in WP (hell, we only had 20+ people with decades of experience with PHP, SQL & Oracle, CodeIgnigter, could we be trusted?) and the development time only got longer. Unified corporate services (like the portability of user accounts)  became fragmented, developers were constantly being redirected by featuritis, and some websites never were finished. From WordPress came service outages that lasted days (we never had more than minutes in the past), constant security patches and updates, and a continual chase where, if you cared to look up, became obvious that for business (who appreciate fixed costs) that the path we took was more expensive than they expected. But clearly it had to be the fault of the developers - management was promised that WP was cheap and easy!

    The Architects left, then Development managers. Front-End teams were the first to feel the cut, then a bit later back-end developers. Project websites closed or were sold off, their managers being fired first, then the teams migrated into corporate, then disposed of soon afterwards (Except email marketing - luckily having a 1998 skills set is still required). The site catalog was cut to 1/3 of previous size (we did over-segment the market, but not by 2/3rds) and crown jewels were sold off. In the end, the company management left, unable to steer their own course. The company was closed, remaining assets sold-off and small chunks of the remaining sales groups were absorbed into the publishing parent.

    And of the sites? Those few that made it are hardly changed from pre-WP versions 2 years old. Most are gone - ah, but the programming mess remains! Here’s a nice trick - Every site requirers a separate account, and some of them have very interesting logic. Ever heard of a site where you couldn’t recover your password by sending an email? Yeah, me neither, but in these cases you needed your email and your handle - not login name, account handle - to recover the account. Let’s face it…that never happens, so old users just had to sign-on as new users. If you’re a kid from 9-16, what difference does abandoning an account mean? Nothing to the kids - but if you as a company can show constant growth in registrants, even if it doesn’t match the page views even remotely, then you can tell your ad network you’re growing. There’s a word for that.

    Yeah, I’ve been holding that in for a while now…

    Let’s recap:
    So to keep costs down, they grabbed free software, segmented development, hired externals to start building without clear, unified development goals (which only doubled costs), dropped or sold-off corporate assets, lost or abandoned market share and let the company collapse onto itself from the top-down.

    I’m pretty sure that part wasn’t in the cold call.

    Via ByBjorn...

    Posted by admin on 03/02 at 10:14 AM
    Posted in:
    (0) TrackbacksPermalink
    Page 2 of 23 pages  <  1 2 3 4 >  Last »