How did you remove the possibility to login ?
If you just kicked the "login" block, you can come back
going directly to /user.php at the root of your site...

Quote:
It's because blocks get processed through smarty...
And by default, it disables processing of php tags within templates (so you can allow someone to update some templates, he won't be able to insert code).
If you're the only one to manipulate templates on your site and you thrust yourself you can change this:

Edit /class/smarty/Smarty.class.php and find this line (in my version it's line 200):

Quote:
and replace it with:
Quote:
I haven't personally tested it, but it should work...

Skalpa.>

Quote:

Agreed. I used to work in a company whose site was translated in 5 languages. Once an article was added in one language, translators team was notified of it, then they could go the the admin interface, click "translate" and the article was duplicated ready to be translated in another language.

If you want to talk of interface stuff, it means:
- One possibility to indicate the languages available somewhere in admin + specifying a default language
- An additional selectbox (containing the above languages) in each form used to submit content, allowing poster to specify which language is used in his post
- A "translate" button available in the forms/admin, so an item can be duplicated and used as a starting point for the translation while staying "linked" with the original
- An additional pref for each user, allowing them to specify one or more languages and the order of preference

Technically, we don't even need to duplicate tables or have separate ones. It's just about creating another table that links content to languages.



transid is the primary key,
newsid allows us to retrieve the news item by itself
univnewsid is what links translations
lang is the language code of this item

Another (and more simple) solution would be to add the 2 (univnewsid + lang) columns to the existing content tables.

So, if we create a entirely new news item, it is added to the news table as usual, and a row with a new univnewsid is also generated.
If we want to translate an already existing news, we duplicate it, change the content, and add another line to the translation table which will have the same univnewsid as the original.
Like this:
- we can query the items in a specific language
- we can also query all the translations of a specific item using the "univ" field (to show a "translate to" selectbox in the article page that will give people access to available translations)
- If using the "additional table" choice, we can even trick the system so the same item is marked as being in different languages, without the information being actually duplicated (i.e: some admins may want a specific english item to appear in all the site even in foreign versions)

etc...

For core/module handling: a little part should be handled by the kernel itself (specifying avail languages / user pref), but module writers will have to take care of the rest (anyway it's not too difficult to implement I think...)



Skalpa.>

Try this one:

http://www.wine-logo.com/user.php



Skalpa.>

Precisely, the resource.db.php problem is coming from an error in this file.
As I said in a previous post you can already get the updated version in CVS if you want, as it has other advantages and works with the 2.0.5 kernel.

The ones coming from /templates_c/xxxxxx.html come from the template files, not really smarty. As a general rule, if you want to use a variable in your template but are not sure it will be defined, you should test for its existence like this:



Skalpa.>

Thanks a lot folks !

The german article describes (I think) what I was planning to do (well, it's even better ), but I believed the fix needed was already done, so I'll ensure it's really fixed in the next release.

In short:
-There's a little fix for common.php
-Then he registers a Smarty "output filter".
These funcs are called after the template has been processed but before it's sent to the browser, so he can replace all the Xoops-like URLs with the one that are in htaccess (the opposite of what Apache does)

Quote:

That's what the trick at the bottom is for (a nice one also): it checks the User-agent string to see if it's a search engine bot and if it is, it will send a custom page (so you can insert all the links you want here), instead of the normal homepage.

Thanks again for all that infos

Skalpa.>

Quote:

Don't think so coz it wasn't possible until recently due to a bug in the kernel.
However, it is now, and I think it could be useful (not specially for search engines, as I think you're right, but also because I think some people would prefer advertising URLs like /news/mytopic/ instead of /modules/news/index.php?storytopic=N).
So I'm seriously investigating all that whould be needed for that to be implemented (coz even if mod_rewrite rules are written, they're useless if the links throughout the site all stay /modules/stuff/?topic=nnn

And also, that's the 2nd time today I see someone wondering about the presence of words in an URL and engines ranking, so I'll try double-checking about that (I'm not sure at all actually, and even your're right in your example, maybe changing a number to a word could be relevant).

Skalpa.>

Quote:

Well, actually all the constants defined in PHP can be accessed in your templates.
Some of the XOOPS ones have been defined directly (like <{$xoops_url}> ), other ones can be accessed with:
<{$smarty.const.DEFINENAME}>

Not sure I see which var you're talking about here, but that may help.

Skalpa.>

There's an option to do this, although it doesn't work in any released version

However, it has been fixed in CVS so it will be ok for next one.
If you can't wait for it, you can get the fixed file (it's resource.db.php) from the CVS repository and copy it manually over the actual one (be careful however: I'm sure you can use it and that it will work with a 2.0.5 kernel, but can't say anything about previous versions).

Once installed: disable theme/tpl caching in System admin / preferences (it's the option called update templates from...).
Then, if you're using the "default" theme, XOOPS will check for an updated version of your templates in /modules/yourmod/templates/ .
Or if you're using a theme called, i.e "mytheme", it will look in /themes/mytheme/templates/yourmod/ .

IMHO: For dev purposes, use the default theme. Otherwise each time you update your module it will recompile the files in the /modules/.... directory, even if you have updated them in /themes/.... , so it's still a bit boring.

Skalpa.>

Welcome m8

You can do that by editing the system templates:
Go to System Admin / Templates, then click List on the System line.
1st one is system_block_login.html (just remove the last link)
then in system_userform.html, remove the following line (that's the "messed login" page ):
<div><{$lang_notregister}><br /></div>

But even if you do that, people will still be able to access the "register.php" page by entering the address manually. So don't forget to remove this file also (in the site root).

Skalpa.>