CMS Made Simple Forums

moscato wrote: yes - i've created a completely new database for that. i just did the install to test 1.2.4 and nothing else 

define('DEFAULT_LANG', 'en_US');
$force_mle_default = true;

$hls = array(

 'en_US' => array(
        'block'=>'en',
        'flag'=>'<img src="images/lang/en_US.png" style="border:0" alt="English" />',
        'text'=>'English',
        'locale'=>'en_US.utf8',
 ),
 'it_IT' => array(
        'block'=>'it',
        'flag'=>'<img src="images/lang/it_IT.png" style="border:0" alt="Italiano" />',
        'text'=>'Italiano',
        'locale'=>'it_IT.utf8@euro',
 ),
 'fr_FR' => array(
        'block'=>'fr',
        'flag'=>'<img src="images/lang/fr_FR.png" style="border:0" alt="Français" />',
        'text'=>'Français',
        'locale'=>'fr_FR.utf8@euro',
 ),

);

.....

.....
        {lang}   {breadcrumbs starttext='You are here' root='Home' delimiter='»'}
.....
        {content view_default=true}

       
{content block="column_right" view_default=true}

.....
      {global_content name='footer' view_default=true}

moscato wrote: what i've discovered is, that in the directory "tmp / templates_c" the corresponding files are EMPTY(!) sometimes. maybe that's the reason why the content is not displayed sometimes..?

moscato wrote: oh my god. that's a bit of shock for me. i've already running CMSMS MLE for my client with the 23 languages. don't know what to do now..?

is it possible to disable caching or to find a good solution for this problem?

moscato wrote: result: i THINK it's working now  that's really great!!

i'm looking forward for the official update 

moscato wrote: my problem is, that i've installed 1.2.3.

is it possbile to update some files manually or to replace the important files, so that my version will work?

Wiedmann wrote: I've also played with this problem, and as you know, there was also a problem with the menu for me (menutext was empty). Well, after some tests, I've found out, that the {title} was also empty.

The result, which is working for me, you can see in the attachment.

--> I don't use a param for {content}, instead I use a constant "DEFAULT_LANG_FALLBACK" in config_lang.php (for the whole page).

+global $mleblock, $mleblockfallback;
+$this->mName = (empty($row->fields["content_name$mleblock"]) && ($mleblockfallback)) ? $row->fields["content_name$mleblockfallback"] : $row->fields["content_name$mleblock"];
+$this->mMenuText = (empty($row->fields["menu_text$mleblock"]) && ($mleblockfallback)) ? $row->fields["menu_text$mleblockfallback"] : $row->fields["menu_text$mleblock"];

alby wrote: ....................

+global $mleblock, $mleblockfallback;
+$this->mName = (empty($row->fields["content_name$mleblock"]) && (!empty($mleblockfallback))) ? $row->fields["content_name$mleblockfallback"] : $row->fields["content_name$mleblock"];
+$this->mMenuText = (empty($row->fields["menu_text$mleblock"]) && (!empty($mleblockfallback))) ? $row->fields["menu_text$mleblockfallback"] : $row->fields["menu_text$mleblock"];

because there is a bug if you add param to content tag.

In this way, for example, class.content.inc.php becomes:

Wiedmann wrote:The result, which is working for me, you can see in the attachment.

Wiedmann wrote:(BTW: It's not ready for the EXTENDED version yet. But I can do this too).

patch -p 1 < default_content_fallback.diff.txt

Wiedmann wrote:

because there is a bug if you add param to content tag.

Sorry, I'm not exactly sure what you mean: You mean there is a bug before or after applying my patch?

Wiedmann wrote:

In this way, for example, class.content.inc.php becomes:

So the main differnce is:
- You are not using a constant, instead you are using a variable.
- There is no need to use the fallback, if we are allready on the default language.
Correct?

Wiedmann wrote: There is also another thing which I want change:
There are some SELECT's, which are using "SELECT *". This should also be changed. Especially for the table "cms_content".