1372
The fix is covered here:
https://xoops.org/modules/newbb/viewtopic.php?topic_id=65575&viewmode=flat&order=ASC&type=&mode=0&start=0
https://xoops.org/modules/newbb/viewtopic.php?topic_id=65575&viewmode=flat&order=ASC&type=&mode=0&start=0
1373
Quote:
Yes, that is the issue, but you did it the best way, with clean and less code. Gotta love your work!
phppp wrote:
I am not sure if it is the same issue covered by rev #2056 & #2060
http://xoops.svn.sourceforge.net/viewvc/xoops?view=rev&revision=2056
http://xoops.svn.sourceforge.net/viewvc/xoops?view=rev&revision=2060
I will check the patch from trabis
Yes, that is the issue, but you did it the best way, with clean and less code. Gotta love your work!
1374
Hi Marco, I took the liberty of applying some fixes to the profile module, including changing database, renaming fields, adding images, removing smartobject references, fixing permissions select box, etc.
You can download it in this temporary link:
http://www.xuups.com/profile_with_fixes.zip
Please check if it is ok for you.
You can download it in this temporary link:
http://www.xuups.com/profile_with_fixes.zip
Please check if it is ok for you.
1375
eventspeak, my previous post was addressed to dslchart.
Yogurt will not run in your XOOPS version unless you assign css and js to xoopsTpl instead of xotheme.
You will have to do something like this in all files:
Search:
Replace:
And i did not test this, it may have some bug there, but you got the ideia.
Yogurt will not run in your XOOPS version unless you assign css and js to xoopsTpl instead of xotheme.
You will have to do something like this in all files:
Search:
/**
* Adding to the module js and css of the lightbox and new ones
*/
$xoTheme->addStylesheet(XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/include/yogurt.css');
$xoTheme->addStylesheet(XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/css/jquery.tabs.css');
// what browser they use if IE then add corrective script.
if(ereg("msie", strtolower($_SERVER['HTTP_USER_AGENT']))) {
$xoTheme->addStylesheet(XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/css/jquery.tabs-ie.css');
}
$xoTheme->addStylesheet(XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/include/jquery.lightbox-0.3.css');
$xoTheme->addScript(XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/include/jquery.js');
$xoTheme->addScript(XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/include/jquery.lightbox-0.3.js');
$xoTheme->addScript(XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/include/yogurt.js');
Replace:
$includeIE = '';
if(ereg("msie", strtolower($_SERVER['HTTP_USER_AGENT']))) {
$includeIE = '<link rel="stylesheet" type="text/css" media="all" href="'.XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/css/jquery.tabs-ie.css" />';
}
$xoopsTpl->assign( 'xoops_module_header' ,
'<link rel="stylesheet" type="text/css" media="all" href="'.XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/include/yogurt.css" />
<link rel="stylesheet" type="text/css" media="all" href="'.XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/css/jquery.tabs.css" />
<link rel="stylesheet" type="text/css" media="all" href="'.XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/include/jquery.lightbox-0.3.css" />
'.$includeIE.'
<script type="text/javascript" src="'.XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/include/jquery.js"></script>
<script type="text/javascript" src="'.XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/include/jquery.lightbox-0.3.js"></script>
<script type="text/javascript" src="'.XOOPS_URL.'/modules/'.$xoopsModule->getVar('dirname').'/include/yogurt.js"></script>
'.$xoopsTpl->get_template_vars("xoops_module_header")
);
And i did not test this, it may have some bug there, but you got the ideia.
1376
Quote:
Can you show us your XOOPS 2.2.x site running yogurt or are you just guessing?
That´s what I thought.
dslchart wrote:
xoops 2.2.x works fine with this version of yogurt
yogurt 3.3 RC2
Can you show us your XOOPS 2.2.x site running yogurt or are you just guessing?
That´s what I thought.
1377
Today I found some bugs in the permissions(visibility) of the new profile module.
One interesting bug was that I could not erase a field view permission. I fixed that and then I cross with another.
I could not set more that one permission for each field.
I think it makes sense that I could make the 'name' field available for:
registered users when viewing registered users profiles
group3 users when viewing admin users profiles
etc...
In fact, looking into the database, I could see that many permissions were set but were not displaying.
I fixed the bug and voila! Many permissions were showing for each field.
Now comes the problem,
The profile_visibility table does not have an autoincrement field, meaning that I have several rows with the same 'field_id' and diferent 'user_group' and 'profile_group'
When I want to delete one of this fields, I cannot use XOOPS API because it will delete all the rows containg that 'field_id' and same goes with updates.
Would it not be nice that XOOPS Api could let us update/delete rows matching a criteria? Yes it would!
And would not be nice if XOOPS Api had something like getObject instead of getObjects so I could retrieve a object (or false) based on a criteria that returns always a single row?
So I would not have to do this:
$myobjects = $object_handler->getObjects($criteria);//here comes un ugly array
$theobjectireallywant=$myobjects[0];//and some other checks to see if it is set or not, blablabla
Now, back to the issue. I think we should add an autoincrement field in the table I mentioned above so we could make the profile module work as expected(and using the current api)
Who is developing this module btw?
One interesting bug was that I could not erase a field view permission. I fixed that and then I cross with another.
I could not set more that one permission for each field.
I think it makes sense that I could make the 'name' field available for:
registered users when viewing registered users profiles
group3 users when viewing admin users profiles
etc...
In fact, looking into the database, I could see that many permissions were set but were not displaying.
I fixed the bug and voila! Many permissions were showing for each field.
Now comes the problem,
The profile_visibility table does not have an autoincrement field, meaning that I have several rows with the same 'field_id' and diferent 'user_group' and 'profile_group'
When I want to delete one of this fields, I cannot use XOOPS API because it will delete all the rows containg that 'field_id' and same goes with updates.
Would it not be nice that XOOPS Api could let us update/delete rows matching a criteria? Yes it would!
And would not be nice if XOOPS Api had something like getObject instead of getObjects so I could retrieve a object (or false) based on a criteria that returns always a single row?
So I would not have to do this:
$myobjects = $object_handler->getObjects($criteria);//here comes un ugly array
$theobjectireallywant=$myobjects[0];//and some other checks to see if it is set or not, blablabla
Now, back to the issue. I think we should add an autoincrement field in the table I mentioned above so we could make the profile module work as expected(and using the current api)
Who is developing this module btw?
1379
You will not have to change anything in the core. Just explore a little the profile module and you will see the light you seek.
Login
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $100.00 |
| Due Date: | May 31 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $100.00 |
 |
|