32
Here are fixes to two bugs I found in modules/system/xoops_config.php
1) Preferences >> Meta Tags and Footer
Select options for Meta Rating are corrupt.
replace
line 678
Quote:
with
Quote:
2) Modules >> Extended Profiles >> Fields : umode [Edit]
Select options for Default are empty.
- also -
kernel/object.php line 344 unserialize() offset 0 of 20
replace
line 199
Quote:
with
Quote:
1) Preferences >> Meta Tags and Footer
Select options for Meta Rating are corrupt.
replace
line 678
Quote:
$modversion['config'][38]['options'] = array("_MD_AM_METAOGEN" => "general", "_MD_AM_METAO14YRS" => "14 years", "_MD_AM_METAOREST" => "restricted", "_MD_AM_METAOMAT", "mature");
with
Quote:
$modversion['config'][38]['options'] = array("_MD_AM_METAOGEN" => "general", "_MD_AM_METAO14YRS" => "14 years", "_MD_AM_METAOREST" => "restricted", "_MD_AM_METAOMAT" => "mature");
2) Modules >> Extended Profiles >> Fields : umode [Edit]
Select options for Default are empty.
- also -
kernel/object.php line 344 unserialize() offset 0 of 20
replace
line 199
Quote:
$modversion['profile']['field'][1]['options'] = array('nest'=>_NESTED, 'flat'=>_FLAT, 'thread'=>_THREADED);
with
Quote:
$modversion['profile']['field'][1]['options'] = array(_NESTED => 'nest', _FLAT => 'flat', _THREADED => 'thread');
33
Hmmm ... seems to have lost my reply, trying again ...
The error you see is exactly what I had. It's a basic XOOPS problem and does not seem related to any particular version of PHP, Apache or MySQL.
If you have phpMyAdmin installed on your machine, you can try executing the SQL in my post, or you can make the change manually as I did. Simply open the xoops_user_profile_field table and browse the rows until you find the one with the value "umode" in the field-name column. Edit that row and replace the current value of the field_options column --
Nested,Flat,Threaded
with --
a:3:{s:4:"nest";s:6:"Nested";s:4:"flat";s:4:"Flat";s:6:"thread";s:8:"Threaded";}
(make sure you have everything exactly correct here, including the braces and double-quotes).
Note, however, that this is not a real fix, but only a temporary workaround. As long as there is a value in the database for the profile field, updating the System or Profiles modules should not cause the problem to reappear. But since I haven't yet found the original source of the invalid data, every new installation of XOOPS 2.2.3/2.2.4 will also need this manual workaround.
It's really fairly easy to do, but if you need more specific help using phpMyAdmin to change the database, please post back here.
The error you see is exactly what I had. It's a basic XOOPS problem and does not seem related to any particular version of PHP, Apache or MySQL.
If you have phpMyAdmin installed on your machine, you can try executing the SQL in my post, or you can make the change manually as I did. Simply open the xoops_user_profile_field table and browse the rows until you find the one with the value "umode" in the field-name column. Edit that row and replace the current value of the field_options column --
Nested,Flat,Threaded
with --
a:3:{s:4:"nest";s:6:"Nested";s:4:"flat";s:4:"Flat";s:6:"thread";s:8:"Threaded";}
(make sure you have everything exactly correct here, including the braces and double-quotes).
Note, however, that this is not a real fix, but only a temporary workaround. As long as there is a value in the database for the profile field, updating the System or Profiles modules should not cause the problem to reappear. But since I haven't yet found the original source of the invalid data, every new installation of XOOPS 2.2.3/2.2.4 will also need this manual workaround.
It's really fairly easy to do, but if you need more specific help using phpMyAdmin to change the database, please post back here.
34
Well, it looks like the places I thought were broken are OK, which means I have no idea what caused the problem. I fixed it, but to do so I had to manually change the value in the database.
The equivalent SQL would be
UPDATE xoops_user_profile_field
SET field_options = 'a:3:{s:4:"nest";s:6:"Nested";s:4:"flat";s:4:"Flat";s:6:"thread";s:8:"Threaded";}'
WHERE field_name = 'umode'
I would really appreciate it if someone can point out where the problem originated.
Thanks.
The equivalent SQL would be
UPDATE xoops_user_profile_field
SET field_options = 'a:3:{s:4:"nest";s:6:"Nested";s:4:"flat";s:4:"Flat";s:6:"thread";s:8:"Threaded";}'
WHERE field_name = 'umode'
I would really appreciate it if someone can point out where the problem originated.
Thanks.
35
I'm using XOOPS 2.2.4 (on my test site for now) - I really need the excellent upgrade to the Admin side, themes, etc.
I can see the cause of this error - there are at least 2 places where the the options array for the "umode" form select field are specified incorrectly. I changed them, but I can't get the change reflected in the database when I update the System and Profiles modules. The umode field in the xoops_user_profile_field table still shows its options to be "Nested,Flat,Threaded" instead of an Array.
From the change log, it looks like the failure to update the profile config options from the system config options was expected to be resolved, but it doesn't seem to be a complete solution.
If someone can tell me how to get the database to update, I'll post the necessary fixes.
Thanks.
I can see the cause of this error - there are at least 2 places where the the options array for the "umode" form select field are specified incorrectly. I changed them, but I can't get the change reflected in the database when I update the System and Profiles modules. The umode field in the xoops_user_profile_field table still shows its options to be "Nested,Flat,Threaded" instead of an Array.
From the change log, it looks like the failure to update the profile config options from the system config options was expected to be resolved, but it doesn't seem to be a complete solution.
If someone can tell me how to get the database to update, I'll post the necessary fixes.
Thanks.
36
Ah, the profile manager stuff does point the way ...
It seems the permissions are completely open-ended, so I can hook in there as well. Now I just need to find a way to gracefully insert my new behavior into the menu generation as well as config categories and config item collection processing.
Still open to anyone else's thoughts/experience on this topic.
It seems the permissions are completely open-ended, so I can hook in there as well. Now I just need to find a way to gracefully insert my new behavior into the menu generation as well as config categories and config item collection processing.
Still open to anyone else's thoughts/experience on this topic.
37
Well, I have some ideas, but it's not just a matter of some code changes. It's a fairly deep intrusion into the core (at minimum a new system table, or possibly a shape change to the existing config table), and I don't want to implement something that does not fit with whatever might already be in the works. I'd like to hear
1) if anyone is already working on this, as I know others have mentioned a need for it before, or
2) if anyone has given the potential architecture any serious thought and can share their ideas
I'm an experienced Smalltalk software engineer, but the architecture of the XOOPS core is still not very clear to me. I don't want to implement something strange.
So please share your ideas.
Thanks.
1) if anyone is already working on this, as I know others have mentioned a need for it before, or
2) if anyone has given the potential architecture any serious thought and can share their ideas
I'm an experienced Smalltalk software engineer, but the architecture of the XOOPS core is still not very clear to me. I don't want to implement something strange.
So please share your ideas.
Thanks.
38
OK, that was obvious 
But someone seems to have envisioned a Help System of some sort and this looks like the hook-in point. Can anyone comment on how it should be implememented? Are the files meant to be linked live into the admin side of the site, or just available for the developer (if they did exist)?
But someone seems to have envisioned a Help System of some sort and this looks like the hook-in point. Can anyone comment on how it should be implememented? Are the files meant to be linked live into the admin side of the site, or just available for the developer (if they did exist)?
39
This may be a topic for the Roadmap folks, but I have just upgraded my test site to 2.2.4 and it neatly solves most of the issues for which I needed system hacks.
Thanks guys this is very nice work!
The primary remaining item is - I need the ability to allow my "Content Editor" users access to a subset of the Webmaster's admin menu items. I would like to do this in a data driven way, much like the config items in xoops_version.php for my modules. The new profile manager stuff is close, but not quite the thing I need.
So, my question is, has anyone looked into permission-based config items -- or is this a feature that is being worked on for a coming release? I'm going to build this one way or another, but I would prefer it to be in the least "hacky" way possible and in line with whatever objectives the devs are working towards.
Can anyone point me in the right direction?
Thanks.
Thanks guys this is very nice work!
The primary remaining item is - I need the ability to allow my "Content Editor" users access to a subset of the Webmaster's admin menu items. I would like to do this in a data driven way, much like the config items in xoops_version.php for my modules. The new profile manager stuff is close, but not quite the thing I need.
So, my question is, has anyone looked into permission-based config items -- or is this a feature that is being worked on for a coming release? I'm going to build this one way or another, but I would prefer it to be in the least "hacky" way possible and in line with whatever objectives the devs are working towards.
Can anyone point me in the right direction?
Thanks.
40
Seems like I must have missed something with the "help" files referenced in the xoops_version.php files in the /modules/system/admin subdirectories. None of these files appear to exist.
I want to use the "help" file to contain admin instructions for my own modules, but I don't see any real examples that I can learn from. Can anyone explain how/where these files are meant to be used by the system?
Thanks.
I want to use the "help" file to contain admin instructions for my own modules, but I don't see any real examples that I can learn from. Can anyone explain how/where these files are meant to be used by the system?
Thanks.
Login
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $100.00 |
| Due Date: | Apr 30 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $100.00 |
 |
|