PEAK XOOPS - Install ALTSYS 
Install ALTSYS
- You cannot open a new topic into this forum
- Guests cannot post into this forum
leco1
From: Porto Alegre
Posts: 93
From: Porto Alegre
Posts: 93
In readme file be informed:
INSTALL:
- set XOOPS_TRUST_PATH into mainfile.php
- copy xoops_trus_path/libs/ in the archive into XOOPS_TRUST_PATH/
- copy html/modules/altsys in the archive into XOOPS_ROOT_PATH/modules/
- install it
Please, add this:
INSTALL:
- set XOOPS_TRUST_PATH into mainfile.php
- copy xoops_trus_path/libs/ in the archive into XOOPS_TRUST_PATH/
- copy html/modules/altsys in the archive into XOOPS_ROOT_PATH/modules/
-replace /xoops_trust_path/libs/altsys/include/altsys_functions.php with the file altsys_functions.php in directory Extra in Xoops 2.3.x.
- install it
For this great module works, it is necessary that this file is in the EXTRAS of XOOPS 2.3.x.
This information should appear in that direction README.
It is commonplace for developers, but not for beginners
Thaks
INSTALL:
- set XOOPS_TRUST_PATH into mainfile.php
- copy xoops_trus_path/libs/ in the archive into XOOPS_TRUST_PATH/
- copy html/modules/altsys in the archive into XOOPS_ROOT_PATH/modules/
- install it
Please, add this:
INSTALL:
- set XOOPS_TRUST_PATH into mainfile.php
- copy xoops_trus_path/libs/ in the archive into XOOPS_TRUST_PATH/
- copy html/modules/altsys in the archive into XOOPS_ROOT_PATH/modules/
-replace /xoops_trust_path/libs/altsys/include/altsys_functions.php with the file altsys_functions.php in directory Extra in Xoops 2.3.x.
- install it
For this great module works, it is necessary that this file is in the EXTRAS of XOOPS 2.3.x.
This information should appear in that direction README.
It is commonplace for developers, but not for beginners
Thaks
Votes:52
Average:5.19
GIJOE
Posts: 4110
Posts: 4110
hi leco.
I've just downloaded the altsys_functions.php and I understand XOOPS 2.3.x from xoops.org is a successor of 2.0.18
I'll modify the file in the next release.
Then, it is not necessary to rewrite the document - "how to install"
I've just downloaded the altsys_functions.php and I understand XOOPS 2.3.x from xoops.org is a successor of 2.0.18
I'll modify the file in the next release.
Then, it is not necessary to rewrite the document - "how to install"
Votes:43
Average:7.21
leco1
From: Porto Alegre
Posts: 93
From: Porto Alegre
Posts: 93
GIGOE
Yes, XOOPS 2.3.x from xoops.org is a successor of 2.0.18.
Now your modules can running in xoops 2.3.x.
Before, in 2.0.18, this was very difficult.
I'll wainting new release to test and i'll disclose this great module and in Xoops Brazil.
Thanks
Yes, XOOPS 2.3.x from xoops.org is a successor of 2.0.18.
Now your modules can running in xoops 2.3.x.
Before, in 2.0.18, this was very difficult.
I'll wainting new release to test and i'll disclose this great module and in Xoops Brazil.
Thanks
Votes:53
Average:5.47
GIJOE
Posts: 4110
Posts: 4110
hi leco.
Though I don't have time to check my modules with the core released from xoops.org, the latest altsys will work fine with XOOPS 2.3.x if their structure is almost identical as ImpressCMS.
Try it please.
Though I don't have time to check my modules with the core released from xoops.org, the latest altsys will work fine with XOOPS 2.3.x if their structure is almost identical as ImpressCMS.
Try it please.
Votes:45
Average:5.78
info
Posts: 16
Posts: 16
I've always found the AltSys functions to be mandatory installation for any XOOPS site, especially for dealing with the management of templates, blocks, and permissions. Don't leave home without it.
I've set it up on my XOOPS 2.3.x install and generally AltSys runs fine (as always). However, I'm getting one small error related to the adminmenu.php file found in the cache folder (now xoops_data/caches/xoops_cache with 2.3.x). Here's what happens....
AltSys inserts some information into the adminmenu.php file and uses it for its own purposes. However, because XOOPS changed their methodology for the admin menu, XOOPS no longer uses or needs the adminmenu.php file, and when any module is updated, the file is deleted by XOOPS. This causes both Protector 3.22 and especially AltSys to throw up an error for some of their functions.
So, you have to somehow keep from deleting this file when a module is updated. Currently, what I'm doing is just touching the file to create it file and then AltSys does it's thing just fine (inserts its code). I've tried changing permissions on it so it can't be removed or overwritten, but that doesn't seem to work. Note: when using the default Control Panel GUI, a file called xoops_adminmenu_XoopsGuiDefault.php is created in the xoops_cache folder (but not when using ThAdmin). The problem exists except when Control Panel GUI is set to 'legacy'.
Otherwise, AltSys works very well (still wish we could manage bottom blocks, but don't use these too often, so not a major issue for me).
FWIW, I'm using AltSys 0.61a on XOOPS 2.3.2b, currently. I haven't tested the error against the other versions of 2.3.x, but I expect that it's the same issue there as well.
I've set it up on my XOOPS 2.3.x install and generally AltSys runs fine (as always). However, I'm getting one small error related to the adminmenu.php file found in the cache folder (now xoops_data/caches/xoops_cache with 2.3.x). Here's what happens....
AltSys inserts some information into the adminmenu.php file and uses it for its own purposes. However, because XOOPS changed their methodology for the admin menu, XOOPS no longer uses or needs the adminmenu.php file, and when any module is updated, the file is deleted by XOOPS. This causes both Protector 3.22 and especially AltSys to throw up an error for some of their functions.
So, you have to somehow keep from deleting this file when a module is updated. Currently, what I'm doing is just touching the file to create it file and then AltSys does it's thing just fine (inserts its code). I've tried changing permissions on it so it can't be removed or overwritten, but that doesn't seem to work. Note: when using the default Control Panel GUI, a file called xoops_adminmenu_XoopsGuiDefault.php is created in the xoops_cache folder (but not when using ThAdmin). The problem exists except when Control Panel GUI is set to 'legacy'.
Otherwise, AltSys works very well (still wish we could manage bottom blocks, but don't use these too often, so not a major issue for me).
FWIW, I'm using AltSys 0.61a on XOOPS 2.3.2b, currently. I haven't tested the error against the other versions of 2.3.x, but I expect that it's the same issue there as well.
Votes:46
Average:6.52
GIJOE
Posts: 4110
Posts: 4110
hi info.
Quote:OK.
It might be caused by the branch of the core types.
Try this hack.
include/adminmenu_functions.php
Quote:Why don't you try Altsys-0.70?
It supports bottom blocks.
At least, I've comfirmed it works fine with ImpressCMS.
leco reported it works properly with XOOPS2.3.
And you'd better know I'm supporting "ALL XOOPS"
- XOOPS 2.0 (original)
- XOOPS 2.0-JP by XOOPS Cube Project
- XOOPS Cube Legacy 2.1
- ImpressCMS
- Oreteki XOOPS
- XOOPS 2.0.x by Skalpa
- XOOPS 2.3.x by phppp
XOOPS 2.3.x is just a kind of various core types for me
Quote:
I've set it up on my XOOPS 2.3.x install and generally AltSys runs fine (as always). However, I'm getting one small error related to the adminmenu.php file found in the cache folder (now xoops_data/caches/xoops_cache with 2.3.x). Here's what happens....
AltSys inserts some information into the adminmenu.php file and uses it for its own purposes. However, because XOOPS changed their methodology for the admin menu, XOOPS no longer uses or needs the adminmenu.php file, and when any module is updated, the file is deleted by XOOPS. This causes both Protector 3.22 and especially AltSys to throw up an error for some of their functions.
So, you have to somehow keep from deleting this file when a module is updated. Currently, what I'm doing is just touching the file to create it file and then AltSys does it's thing just fine (inserts its code). I've tried changing permissions on it so it can't be removed or overwritten, but that doesn't seem to work. Note: when using the default Control Panel GUI, a file called xoops_adminmenu_XoopsGuiDefault.php is created in the xoops_cache folder (but not when using ThAdmin). The problem exists except when Control Panel GUI is set to 'legacy'.
It might be caused by the branch of the core types.
Try this hack.
include/adminmenu_functions.php
//
// insert/replace items of mymenu into adminmenu
//
function altsys_adminmenu_insert_mymenu( &$module )
{
global $altsysModuleConfig ;
if( empty( $altsysModuleConfig['adminmenu_insert_mymenu'] ) ) return ;
if( altsys_get_core_type() < ALTSYS_CORE_TYPE_ORE ) {
if( altsys_get_core_type() == ALTSYS_CORE_TYPE_X20 ) {
altsys_adminmenu_insert_mymenu_x20( $module ) ;
}
}
Quote:
Otherwise, AltSys works very well (still wish we could manage bottom blocks, but don't use these too often, so not a major issue for me).
FWIW, I'm using AltSys 0.61a on XOOPS 2.3.2b, currently. I haven't tested the error against the other versions of 2.3.x, but I expect that it's the same issue there as well.
It supports bottom blocks.
At least, I've comfirmed it works fine with ImpressCMS.
leco reported it works properly with XOOPS2.3.
And you'd better know I'm supporting "ALL XOOPS"
- XOOPS 2.0 (original)
- XOOPS 2.0-JP by XOOPS Cube Project
- XOOPS Cube Legacy 2.1
- ImpressCMS
- Oreteki XOOPS
- XOOPS 2.0.x by Skalpa
- XOOPS 2.3.x by phppp
XOOPS 2.3.x is just a kind of various core types for me
Votes:56
Average:5.54
info
Posts: 16
Posts: 16
Quote:Howdy back (mboyden on XOOPS) and thanks for your great modules.
Quote:Unfortunately, it didn't work. The file is still removed by the core during a module update and AltSys still gives me the "Rebuild adminmenu" error and redirects to the main admin page.
Quote:Of course! I always try to run the latest greatest. As to working in XOOPS 2.3.x, I'm not getting that at this point. What I get is a text box (name=extra_sides[X]) next to the none radio button that provides the following symptoms upon these bottom block selections:
- bottom left: side = "none", extra_sides empty
- bottom center: side undefined, extra_sides = 9
- bottom right: side undefined, extra_sides = 8
Changing the value in extra_sides doesn't make a difference, it seems. I guess I'll need to see what *should* be happening.
Quote:Yeah, I've seen that, and it's great. I'm impressed. However, I haven't yet played with the XOOPS forks at this point.
Many thanks for a great module! Let me know if I can help troubleshoot both the adminmenu.php issue as well as the ability to use/support bottom blocks in XOOPS 2.3.x (I'm also checking both using ThAdmin as well as legacy control panel GUIs).
GIJOE wrote:
hi info.
Quote:
It might be caused by the branch of the core types.
Try this hack.
include/adminmenu_functions.php
Quote:
Why don't you try Altsys-0.70?
It supports bottom blocks.
At least, I've comfirmed it works fine with ImpressCMS.
leco reported it works properly with XOOPS2.3.
- bottom left: side = "none", extra_sides empty
- bottom center: side undefined, extra_sides = 9
- bottom right: side undefined, extra_sides = 8
Changing the value in extra_sides doesn't make a difference, it seems. I guess I'll need to see what *should* be happening.
Quote:
And you'd better know I'm supporting "ALL XOOPS"
- XOOPS 2.0 (original)
- XOOPS 2.0-JP by XOOPS Cube Project
- XOOPS Cube Legacy 2.1
- ImpressCMS
- Oreteki XOOPS
- XOOPS 2.0.x by Skalpa
- XOOPS 2.3.x by phppp
XOOPS 2.3.x is just a kind of various core types for me
Many thanks for a great module! Let me know if I can help troubleshoot both the adminmenu.php issue as well as the ability to use/support bottom blocks in XOOPS 2.3.x (I'm also checking both using ThAdmin as well as legacy control panel GUIs).
Votes:58
Average:5.52
GIJOE
Posts: 4110
Posts: 4110
hi info.
I've found a curious behavior in your post.
Quote:'extra_sides' should not be displayed for XOOPS >= 2.0.14
Perhaps, it might be a bug in the recognition of versions.
Check the codes in include/altsys_functions.php
I've found a curious behavior in your post.
Quote:
Changing the value in extra_sides doesn't make a difference, it seems. I guess I'll need to see what *should* be happening.
Perhaps, it might be a bug in the recognition of versions.
Check the codes in include/altsys_functions.php
define( 'ALTSYS_CORE_TYPE_X20' , 1 ) ; // 2.0.0-2.0.13 and 2.0.x-JP
define( 'ALTSYS_CORE_TYPE_X20S' , 2 ) ; // 2.0.14- and 2.3.0- from xoops.org
define( 'ALTSYS_CORE_TYPE_ORE' , 4 ) ; // ORETEKI by marijuana
define( 'ALTSYS_CORE_TYPE_X22' , 8 ) ; // 2.2 from xoops.org
define( 'ALTSYS_CORE_TYPE_ICMS' , 12 ) ; // ImpressCMS
define( 'ALTSYS_CORE_TYPE_XC21L' , 16 ) ; // XOOPS Cube 2.1 Legacy
function altsys_get_core_type()
{
if( defined( 'XOOPS_ORETEKI' ) ) return ALTSYS_CORE_TYPE_ORE ;
else if( defined( 'XOOPS_CUBE_LEGACY' ) ) return ALTSYS_CORE_TYPE_XC21L ;
else if( defined( 'ICMS_VERSION_NAME' ) ) return ALTSYS_CORE_TYPE_ICMS ;
else if( strstr( XOOPS_VERSION , 'JP' ) ) return ALTSYS_CORE_TYPE_X20 ;
else {
$versions = array_map( 'intval' , explode( '.' , preg_replace( '/[^0-9.]/' , '' , XOOPS_VERSION ) ) ) ;
if( $versions[0] == 2 && $versions[1] == 2 ) {
return ALTSYS_CORE_TYPE_X22 ;
} else if( $versions[0] == 2 && $versions[1] == 0 && $versions[2] > 13 ) {
return ALTSYS_CORE_TYPE_X20S ;
} else if( $versions[0] == 2 && $versions[1] > 2 ) {
return ALTSYS_CORE_TYPE_X20S ;
} else {
return ALTSYS_CORE_TYPE_X20 ;
}
}
}
Votes:11
Average:7.27
GIJOE
Posts: 4110
Posts: 4110
I've confirmed it.
And the answer is
Just disable "Rewrite admin menu" in altsys preferences.
And the answer is
Just disable "Rewrite admin menu" in altsys preferences.
Votes:9
Average:8.89
info
Posts: 16
Posts: 16
One down, one to go....
Quote:That almost does it. You also have to set "Copy mymenu links into admin menu" to No. THEN it works. Thanks for the assistance on that piece.
Quote:I checked the logic of the code you posted and it correctly returns X20S as the core type value of 2 before selecting/creating the class. However, I'm still getting the 'extra_sides' code in the Module Blocks area. Tested it with ThAdmin turned off (set to 'legacy'), too.
I looked at some of the code, and it appears that the X20S class code seems to be picking up the basic MyBlocksAdmin renderCell4BlockPosition function code instead of the ICMS code based on the HTML being produced. A brief look at the code tells me it'd take some time to delve into this logic., but I'm surprised that it's working on the 2.0.14+ correctly series.
Quote:
GIJOE wrotes:
Just disable "Rewrite admin menu" in altsys preferences.
Quote:
GIJOE wrotes:
'extra_sides' should not be displayed for XOOPS >= 2.0.14
Perhaps, it might be a bug in the recognition of versions.
I looked at some of the code, and it appears that the X20S class code seems to be picking up the basic MyBlocksAdmin renderCell4BlockPosition function code instead of the ICMS code based on the HTML being produced. A brief look at the code tells me it'd take some time to delve into this logic.
, but I'm surprised that it's working on the 2.0.14+ correctly series.
Votes:12
Average:7.50
GIJOE
Posts: 4110
Posts: 4110
hi info.
Just try altsys-0.71
Just try altsys-0.71
Votes:9
Average:8.89
info
Posts: 16
Posts: 16
Quote:Thanks, GIJOE; 0.71a fixed that issue. Working now. Yeehaw!
GIJOE wrote:
Just try altsys-0.71
Votes:10
Average:10.00
2key
Posts: 6
Posts: 6
Hey guys/gals,
Downloaded altsys 0.7, I believe i need it in order to have d3forum, and maybe some other functionality I have not articulated yet. I am currently using the latest version of xoops. However, I have a ghost of the site also on 2.0.17 to test all modules and custom hacks, etc for compatibility.
My question is..
1. Can someone please explain these instructions
INSTALL:
- set XOOPS_TRUST_PATH into mainfile.php
- copy xoops_trus_path/libs/ in the archive into XOOPS_TRUST_PATH/
- copy html/modules/altsys in the archive into XOOPS_ROOT_PATH/modules/
- install it
(I don't know where the trust path variable is and what needs to be done to it)
2.There are two folders in the package,im not sure where html folder goes.
Im confused on the overall installation , maybe Im overlooking some simple things.
If anyone needs me to test/ debug anything while i have these two platforms hosted, let me know, because I've seen alot of issues/questions during research.
Thanks
Downloaded altsys 0.7, I believe i need it in order to have d3forum, and maybe some other functionality I have not articulated yet. I am currently using the latest version of xoops. However, I have a ghost of the site also on 2.0.17 to test all modules and custom hacks, etc for compatibility.
My question is..
1. Can someone please explain these instructions
INSTALL:
- set XOOPS_TRUST_PATH into mainfile.php
- copy xoops_trus_path/libs/ in the archive into XOOPS_TRUST_PATH/
- copy html/modules/altsys in the archive into XOOPS_ROOT_PATH/modules/
- install it
(I don't know where the trust path variable is and what needs to be done to it)
2.There are two folders in the package,im not sure where html folder goes.
Im confused on the overall installation , maybe Im overlooking some simple things.
If anyone needs me to test/ debug anything while i have these two platforms hosted, let me know, because I've seen alot of issues/questions during research.
Thanks
Votes:11
Average:6.36
davidl2
Posts: 5
Posts: 5
Some information about trustpath here:
http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=101
The files in "html" directory go in your "normal" area (content of "module" subdirectory in "modules" directory... if you use Xoops Cube Legacy - put "preload" content in "preload" directory - otherwise ignore.
The files in "xoops_trust_path" directory go into the "xoops-trust_path" directory... when you have read the article above, you will understand this better.
http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=101
The files in "html" directory go in your "normal" area (content of "module" subdirectory in "modules" directory... if you use Xoops Cube Legacy - put "preload" content in "preload" directory - otherwise ignore.
The files in "xoops_trust_path" directory go into the "xoops-trust_path" directory... when you have read the article above, you will understand this better.
Votes:7
Average:10.00
2key
Posts: 6
Posts: 6
Thanks for your quick response.
I'll work on that
thanks
I'll work on that
thanks
Votes:7
Average:10.00
2key
Posts: 6
Posts: 6
Ive tried altsys .71 on xoops 2.0.17 and 2.3.2b.
For some reason I get this message on 2.3.2b above the module on the admin section "install the latest altsys", even if the module is uninstalled(I have d3forum loaded but its not showing).
Ive tried several different versions of altsys but that message remains.
On 2.0.17 it installs alt sys vers .71 the module doesnt show up on admin page, but the link to it on nav menu shows and leeds to a page that says this message
Fatal error: Call to undefined function: xoops_gethandler() in /home/**/domains/***.com/public_html/***/modules/altsys/include/altsys_functions.php on line 9
..still researching.. trying other altsys versions etc.
Im obviously missing something, although i have read everything about these modules on this site and what is found by google. So I will start over with a fresh install.
For some reason I get this message on 2.3.2b above the module on the admin section "install the latest altsys", even if the module is uninstalled(I have d3forum loaded but its not showing).
Ive tried several different versions of altsys but that message remains.
On 2.0.17 it installs alt sys vers .71 the module doesnt show up on admin page, but the link to it on nav menu shows and leeds to a page that says this message
Fatal error: Call to undefined function: xoops_gethandler() in /home/**/domains/***.com/public_html/***/modules/altsys/include/altsys_functions.php on line 9
..still researching.. trying other altsys versions etc.
Im obviously missing something, although i have read everything about these modules on this site and what is found by google. So I will start over with a fresh install.
Votes:7
Average:10.00
2key
Posts: 6
Posts: 6
SO..
Ive installed xoops cube, Uploaded altsys 7. into modules folder.
When install is attempted this error message is received.
Fatal error: main(): Failed opening required '/libs/altsys/xoops_version.php'
(include_path='.:/usr/local/lib/php') in
/home/**/domains/***/public_html/***/html/modules/altsys/xoops_version.php on line 10
Warning [PHP]: main(): open_basedir restriction in effect. File(/libs/altsys/xoops_version.php) is not within
the allowed path(s): (/home/**/:/tmp:/usr/local/lib/php/) in file modules/altsys/xoops_version.php line 10
Warning [PHP]: main(/libs/altsys/xoops_version.php): failed to open stream: Operation not permitted in file
modules/altsys/xoops_version.php line 10
Do I need root access to my server? Or is this something else.
Ive installed xoops cube, Uploaded altsys 7. into modules folder.
When install is attempted this error message is received.
Fatal error: main(): Failed opening required '/libs/altsys/xoops_version.php'
(include_path='.:/usr/local/lib/php') in
/home/**/domains/***/public_html/***/html/modules/altsys/xoops_version.php on line 10
Warning [PHP]: main(): open_basedir restriction in effect. File(/libs/altsys/xoops_version.php) is not within
the allowed path(s): (/home/**/:/tmp:/usr/local/lib/php/) in file modules/altsys/xoops_version.php line 10
Warning [PHP]: main(/libs/altsys/xoops_version.php): failed to open stream: Operation not permitted in file
modules/altsys/xoops_version.php line 10
Do I need root access to my server? Or is this something else.
Votes:10
Average:10.00
Previous post
-
Next post
|
Parent
-
No child
|
Posted on 2009/3/21 2:52
wikeyIMS
Posts: 3
Posts: 3
hi! i just got the same problem.
i(well, my hoster did it for me and "owned" it to my user" created the trust path outside the httpdocs and i get the basedir restriction. i told my hoster to include the trustpath to the "open_basedir" "function".
since i did this right now, i'll post if it ok then. the baserdirs are sortet like: xyz/zyx/yzx/httpdocs:/tmp for example. so httpdocs and everything under tmp is within the basedir and hence not restricted and witin the "allowed path(s). i'm curious if it work whe he adds to .../httpdocs:/tmp:/trust_path :)
i(well, my hoster did it for me and "owned" it to my user" created the trust path outside the httpdocs and i get the basedir restriction. i told my hoster to include the trustpath to the "open_basedir" "function".
since i did this right now, i'll post if it ok then. the baserdirs are sortet like: xyz/zyx/yzx/httpdocs:/tmp for example. so httpdocs and everything under tmp is within the basedir and hence not restricted and witin the "allowed path(s). i'm curious if it work whe he adds to .../httpdocs:/tmp:/trust_path :)
Votes:7
Average:10.00
Login