2
Hello,
I'm looking for the latest version of Multimenu. It must be 2.06, which is a bit dated, but there's a 404 error on the download site.
Has anyone kept it by any chance?
I'm looking for the latest version of Multimenu. It must be 2.06, which is a bit dated, but there's a 404 error on the download site.
Has anyone kept it by any chance?
3
Bonsoir,
Yes in all cases I correct by putting the name of the image after the smarty tag like that I no longer have a problem.
JJDai
Yes in all cases I correct by putting the name of the image after the smarty tag like that I no longer have a problem.
<img src="<{$modPathIcon16}>/arrows/down-1.png" title="<{$smarty.const._AM_SLIDER_DOWN}>"> JJDai
4
a very little remark :
in the bottom af admin:
Powered by XOOPS 2.5.12-Beta1 © 2001-2024
instead
Powered by XOOPS 2.5.12-Beta2 © 2001-2024
in the bottom af admin:
Powered by XOOPS 2.5.12-Beta1 © 2001-2024
instead
Powered by XOOPS 2.5.12-Beta2 © 2001-2024
5
Hello,
I have been testing xoops 2.5.12 on a preproduction site for 10 days.
I have not encountered any major problems, however there is a problem that is not a bug, but rather a regression with the smarty plugins xoModuleIcons16 , xoModuleIcons32 , ....
in many old modules we can see in the templates:
The name of the icon is without apostrophes, because the old function received a string of characters with apostrophes, if there were apostrophes, the image was simply not displayed.
with xoops 2.5.12 you have to write:
with apostrophes.
The function receives an array and if the apostrophes are missing it bugs, which is normal behavior.
the problem is that if we have several sites with different versions it will be a bit problematic to maintain these modules.
If we leave without apostrophes to bug with xoops 2.5.12
if we put the apostrophes it causes problems with previous versions.
so I modify by putting the name of the icon after the smarty tag to not have a problem on the different versions, 2.5.10, 2.5.11, and 2.5.12
Thanks for the work done on this version, JJDai
I have been testing xoops 2.5.12 on a preproduction site for 10 days.
I have not encountered any major problems, however there is a problem that is not a bug, but rather a regression with the smarty plugins xoModuleIcons16 , xoModuleIcons32 , ....
in many old modules we can see in the templates:
The name of the icon is without apostrophes, because the old function received a string of characters with apostrophes, if there were apostrophes, the image was simply not displayed.
with xoops 2.5.12 you have to write:
with apostrophes.
The function receives an array and if the apostrophes are missing it bugs, which is normal behavior.
the problem is that if we have several sites with different versions it will be a bit problematic to maintain these modules.
If we leave without apostrophes to bug with xoops 2.5.12
if we put the apostrophes it causes problems with previous versions.
so I modify by putting the name of the icon after the smarty tag to not have a problem on the different versions, 2.5.10, 2.5.11, and 2.5.12
Thanks for the work done on this version, JJDai
6
Bonjour,
dans modulebuilder Y-a-t-il une petite documentation sur les options des champs dans les tables car je ne saisi pas toute les subtilités
In modulebuilder Is there a small documentation on the options of the fields in the tables because I do not understand all the subtleties
Field: Is parent Ok
Admin: In Files ?
Admin: Visible in list Ok
Admin: Visible in form Ok
User: In Files ?
User index: in header ?
User index: in body ?
User index: in footer ?
User file: in header ?
User file: in body ?
User file: in footer ?
Block: In Files ?
Search: Index Ok
Field: Required Ok
Table: Main Field ?
Thanks for this module
dans modulebuilder Y-a-t-il une petite documentation sur les options des champs dans les tables car je ne saisi pas toute les subtilités
In modulebuilder Is there a small documentation on the options of the fields in the tables because I do not understand all the subtleties
Field: Is parent Ok
Admin: In Files ?
Admin: Visible in list Ok
Admin: Visible in form Ok
User: In Files ?
User index: in header ?
User index: in body ?
User index: in footer ?
User file: in header ?
User file: in body ?
User file: in footer ?
Block: In Files ?
Search: Index Ok
Field: Required Ok
Table: Main Field ?
Thanks for this module
8
Bonjour
-------------
I am testing 2.5.5 and of course i look at the date in french.
With
define("_CAL_FORMAT","Y-m-d");
No problem but it is not french format
but with (french format)
define("_CAL_FORMAT","d-m-Y");
or
define("_CAL_FORMAT","d/m/Y");
The date is in bad format.
I think that the probleme is not resolved because, it is the module that must transform the date the good format, or it's a good way.
I think that the real solution is that the module send a timestamp unix to the class xoopsformcalendar, the calendar show date as langue and it send a timstamp to the module wiche save it in mysql.
(timestamp or universal date)
In the good way i think the processus mus be like this:
Mysql --> format date or datetime (2012-02-10 21:09:08)
module send to calendar ---> format date or datetime (2012-02-10 21:09:08)
calendar show date in format of land (french 10-02-2012 jj-mm-YYYY)
Change the date ---> (exemple : 25-01-2012 21:09:08)
When form is validate
calendar must send to the module --->Mysql format (2012-01-25 21:09:08)
module save as mysql format (2012-01-25 21:09:08) independant of language
May be, to keep compatibility, the best is to pass by a new calendar in this way.
I hpope that i am explicit.
For the rest i have not again notice any problème, but i continue my tests
JJdai
-------------
I am testing 2.5.5 and of course i look at the date in french.
With
define("_CAL_FORMAT","Y-m-d");
No problem but it is not french format
but with (french format)
define("_CAL_FORMAT","d-m-Y");
or
define("_CAL_FORMAT","d/m/Y");
The date is in bad format.
I think that the probleme is not resolved because, it is the module that must transform the date the good format, or it's a good way.
I think that the real solution is that the module send a timestamp unix to the class xoopsformcalendar, the calendar show date as langue and it send a timstamp to the module wiche save it in mysql.
(timestamp or universal date)
In the good way i think the processus mus be like this:
Mysql --> format date or datetime (2012-02-10 21:09:08)
module send to calendar ---> format date or datetime (2012-02-10 21:09:08)
calendar show date in format of land (french 10-02-2012 jj-mm-YYYY)
Change the date ---> (exemple : 25-01-2012 21:09:08)
When form is validate
calendar must send to the module --->Mysql format (2012-01-25 21:09:08)
module save as mysql format (2012-01-25 21:09:08) independant of language
May be, to keep compatibility, the best is to pass by a new calendar in this way.
I hpope that i am explicit.
For the rest i have not again notice any problème, but i continue my tests
JJdai
9
bonjour:
I did not understand everything, but I'll watch that and integers this new template..
On witch version ha you this problème.
JJDai
I did not understand everything, but I'll watch that and integers this new template..
On witch version ha you this problème.
JJDai
10
Hello
I think it's not
Quote:
but
Quote:
And why not correct the file global.php directly in the french distribution ?
JJDai
I think it's not
Quote:
define('_SHORTDATESTRING', 'd-m-Y');
but
Quote:
define('_SHORTDATESTRING', 'Y-m-d');
And why not correct the file global.php directly in the french distribution ?
JJDai
Login
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | AU$15.00 |
| Due Date: | Jul 31 |
| Gross Amount: | AU$0.00 |
| Net Balance: | AU$0.00 |
| Left to go: | AU$15.00 |
 |
|