1
skalpa
Re: MultiSite Hack for Xoops 2.0.13.2
  • 2006/10/27 5:12

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Quote:
I already have the main site up and running, this module requires that i change the first site. I would rather just call the user table from the first sites database and then the second site can have its own modules seperate from the first. Probably not possible.


Well, that's exactly what the system I described to nekro does. And to correct him: it doesn't require MySQL 5... it uses the MySQL MERGE storage engine which has been introduced in MySQL 3.23.25.

Here's how to use it:
- Install the 1st site, using the DB prefix "site1"
- Install the 2nd site, using the DB prefix "site2"
- Use phpMyAdmin to execute the following queries

DROP TABLE site2_groups;
CREATE TABLE site2_groups (
  
groupid smallint(5unsigned NOT NULL auto_increment,
  
name varchar(50NOT NULL default '',
  
description text NOT NULL,
  
group_type varchar(10NOT NULL default '',
  
KEY groupid (groupid),
  
KEY group_type (group_type)
TYPE=MERGE UNION=(site1_groupsINSERT_METHOD=FIRST;

DROP TABLE site2_groups_users_link;
CREATE TABLE site2_groups_users_link (
  
linkid mediumint(8unsigned NOT NULL auto_increment,
  
groupid smallint(5unsigned NOT NULL default '0',
  
uid mediumint(8unsigned NOT NULL default '0',
  
KEY linkid (linkid),
  
KEY groupid_uid (groupid,uid)
TYPE=MERGE UNION=(site1_groups_users_linkINSERT_METHOD=FIRST;

DROP TABLE site2_users;
CREATE TABLE site2_users (
  
uid mediumint(8unsigned NOT NULL auto_increment,
  
name varchar(60NOT NULL default '',
  
uname varchar(25NOT NULL default '',
  
email varchar(60NOT NULL default '',
  
url varchar(100NOT NULL default '',
  
user_avatar varchar(30NOT NULL default 'blank.gif',
  
user_regdate int(10unsigned NOT NULL default '0',
  
user_icq varchar(15NOT NULL default '',
  
user_from varchar(100NOT NULL default '',
  
user_sig tinytext NOT NULL,
  
user_viewemail tinyint(1unsigned NOT NULL default '0',
  
actkey varchar(8NOT NULL default '',
  
user_aim varchar(18NOT NULL default '',
  
user_yim varchar(25NOT NULL default '',
  
user_msnm varchar(100NOT NULL default '',
  
pass varchar(32NOT NULL default '',
  
posts mediumint(8unsigned NOT NULL default '0',
  
attachsig tinyint(1unsigned NOT NULL default '0',
  
rank smallint(5unsigned NOT NULL default '0',
  
level tinyint(3unsigned NOT NULL default '1',
  
theme varchar(100NOT NULL default '',
  
timezone_offset float(3,1NOT NULL default '0.0',
  
last_login int(10unsigned NOT NULL default '0',
  
umode varchar(10NOT NULL default '',
  
uorder tinyint(1unsigned NOT NULL default '0',
  
notify_method tinyint(1NOT NULL default '1',
  
notify_mode tinyint(1NOT NULL default '0',
  
user_occ varchar(100NOT NULL default '',
  
bio tinytext NOT NULL,
  
user_intrest varchar(150NOT NULL default '',
  
user_mailok tinyint(1unsigned NOT NULL default '1',
  
PRIMARY KEY  (uid),
  
KEY uname (uname),
  
KEY email (email),
  
KEY uiduname (uid,uname),
  
KEY unamepass (uname,pass)
TYPE=MERGE UNION=(site1_usersINSERT_METHOD=FIRST;


(if you didn't use site1/site2 when installing, edit the queries)

This will delete the site2 users/groups tables, and create "virtual" ones that point to the equivalent site1 tables. So, in the facts there is only 1 list of users/groups that is used by both sites.

There's no need to hack anything, and if the users table format is modified in a future version, there will be no problem to upgrade... just ensure you upgrade "site1" first, and the subsites after.

PS: I just wrote the queries while posting this, so make a backup of these 3 tables before trying, there might be a typo in the SQL... you never now.
PS2: If you have control over your MySQL permissions, you can even change the queries to have the site2 tables point to tables in another database, by replacing "site1_xxx" by "thesite1db.site1_xxx". Just ensure the MySQL user used by subsites have access to the users/groups/users_groups_link tables of the main site database.
PS3: If you don't understand PS2, forget about it... Just install all site using the same database/user/pwd, and use different prefixes.
Any intelligent fool can make things bigger, and more complex. It takes a touch of genius, a lot of courage, to move in the opposite direction.
Two things are infinite: the universe and human stupidity; and I'm not sure about the 1st one (A.Einstein)



2
skalpa
Re: Session garbage collection bug when using custom sessions
  • 2006/7/10 18:44

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


You're right in your analysis, now this is not a "bug", it's normal behavior. What you're pointing is that it's a nonsense to have gc_maxlifetime smaller than session_expire.

Now the fact the custom session settings allow you to customize session_expire, but not gc_maxlifetime is a problem.

1) It's been temporarily solved in 2.0.14 (in common.php, line 245, gc_maxlifetime is forced so it's equal to session_expire)
2) It's been completely handled in the 2.3 branch, where the session preferences panel gives you the possibility to change a lot more settings than before (like gc_maxlifetime, gc_probability...)

skalpa.>
Any intelligent fool can make things bigger, and more complex. It takes a touch of genius, a lot of courage, to move in the opposite direction.
Two things are infinite: the universe and human stupidity; and I'm not sure about the 1st one (A.Einstein)



3
skalpa
Re: 2.0.14 Upgrade with content invalid errors from xoops_md5.php
  • 2006/6/29 2:15

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


The tar.gz package contains an incorrect xoops.md5 file
I'll update it, it the only error you got are about those 3 files, ignore them.

skalpa.>
Any intelligent fool can make things bigger, and more complex. It takes a touch of genius, a lot of courage, to move in the opposite direction.
Two things are infinite: the universe and human stupidity; and I'm not sure about the 1st one (A.Einstein)



4
skalpa
Re: All pages blank after installation - I followed link above to get debugging switched on and.....
  • 2006/6/28 17:13

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Quote:
Back off to PHP 4. Version 5 doesn't seem to work for some reason with Xoops.


XOOPS completely works with PHP5, I personally develop using PHP 5.2-dev (now, it depends on the modules you use: it may not be the case for all).
The notices by themeselves do not mean anything doesn't work, nevertheless, upgrading to 2.0.14 will make them disappear.

The message you got just means your theme is not correctly installed: maybe you installed the theme incorrectly or renamed its folder (some themes do not allow you to do this).

skalpa.>
Any intelligent fool can make things bigger, and more complex. It takes a touch of genius, a lot of courage, to move in the opposite direction.
Two things are infinite: the universe and human stupidity; and I'm not sure about the 1st one (A.Einstein)



5
skalpa
Re: WF-Links is not displaying links in Category Listings
  • 2006/6/22 13:03

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


I found the bug in WF-Links that makes it incompatible with XOOPS 2.0.14.
The point is that it's really a WF-Links problem that was invisible with old versions, and manifests itself now that I changed the XoopsForm output to make it standard compliant, so there was nothing really possible on XOOPS side.

The problem: the "add link" admin page contains 2 form elements named "cid". One is an hidden element whose value is always 0, the other one is the category selectbox.
With 2.0.13, the hidden element was displayed before the other one, so it seems the posted value was the one of the selectbox.
2.0.14 does not write hidden elements between <tr> tags anymore (as it's invalid HTML), but after the other ones, and now the new link is created with a category ID of "0" (the value of the hidden form element).

So, to make WF-Links work you have to remove this hidden element that shouldn't be here anyway:
in admin/index.php (around line 95 in my version), remove this line
Quote:
$sform -> addElement( new XoopsFormHidden( 'cid', $cid ) );


and that should fix it

EDIT: McDonald fiexd it already as far as I could see... sorry for this useless post .
Any intelligent fool can make things bigger, and more complex. It takes a touch of genius, a lot of courage, to move in the opposite direction.
Two things are infinite: the universe and human stupidity; and I'm not sure about the 1st one (A.Einstein)



6
skalpa
Re: Site is Selling Xoops
  • 2006/6/16 21:18

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


If you got this as a single package, then would you mind sending us back a copy of the source files you got ?

According to the GPL, as James said, they don't have the rights to restrict people on their own additions, so it would be nice to be able to check what they changed and see if we can't make everybody benefit from those changes.

It would be a fair return.
Any intelligent fool can make things bigger, and more complex. It takes a touch of genius, a lot of courage, to move in the opposite direction.
Two things are infinite: the universe and human stupidity; and I'm not sure about the 1st one (A.Einstein)



7
skalpa
Re: Code-Plus 1.0 alpha version was released!!!
  • 2006/6/11 21:37

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Well, I don't like to disturb others' way to handle their own part, but I'd like to give my 2c here for once.

In general, I don't think xoops.org should be an advertising platform for other products (whether these are forks or not doesn't change anything here IMO). Talking about other similar programs in constructive discussions is OK, but I'll agree with the moderation of free threads like this one.

Now, when it comes to "forks" in particular here's my personal position on the two recent ones:
- I'm thinking of adding a link to the XOOPS Cube site somewhere in the new xoops.org. There are many reasons behind this, one being the will to clarify the situation between these projects that use a similar name, and another being that both our dev team and the japanese one communicate and respect each other, sharing information about security issues that arise, and sharing the vision that open-source projects compete by trying to be the best, not by using filthy tricks like this one.
- I'm far from having this opinion of code-plus. Catzwolf is one person who was given the code of the XOOPS modules 3 years ago: he just took them, made them his own, starting to develop them alone without contributing anything back and putting an end to an age where development of modules meant enhancements to the core. Now he's doing the same with the core itself: his multilang code is phppp's, his LDAP code is pemen's (both XOOPS core devs)... and next to this, the credits file or changelog that were here have been completely removed, replaced with a file just naming him as "Developers". Thus, I don't really appreciate that. He's allowed to do what he wants, but I believe "we" already give him enough already, and that maybe he should find another place for his promotion.

But again, it's just a personal opinion, so I'll accept your decision whatever it is.

skalpa.>
Any intelligent fool can make things bigger, and more complex. It takes a touch of genius, a lot of courage, to move in the opposite direction.
Two things are infinite: the universe and human stupidity; and I'm not sure about the 1st one (A.Einstein)



8
skalpa
Re: Groupform Hack for CenterDown Blocks for Xoops 2.0.14-RC1
  • 2006/6/11 14:43

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Quote:
I tried the fix and it did indeed allow the blocks placed in the center column bottom(below content) to be seen in the groups admin. But the blocks from the center column bottom were in with the other center blocks.


It's because what I did is just a quick fix: I'm actually busy preparing 2.0.14, and one of first things I'd like to work on once this is done will be to redo both the groups and blocks administration page entirely to something really more convenient than what there is now, so you won't have this problem eternally .

skalpa.>
Any intelligent fool can make things bigger, and more complex. It takes a touch of genius, a lot of courage, to move in the opposite direction.
Two things are infinite: the universe and human stupidity; and I'm not sure about the 1st one (A.Einstein)



9
skalpa
Re: Howto get the current block id?
  • 2006/5/23 3:51

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


As stupid as it sounds, you can't... (but you're free to post it as a feature request, it would be a no-risk 5mins change ).
Anyway, if you really need that right now, you can find the following lines in class/xoopsblock.php:
// execute the function
                    
$block $show_func($options);
                    if ( !
$block ) {
                        return 
false;
                    }

and replace the function call by $show_func( $options, $this );

once this is done, you should get the current XoopsBlock object instance passed as a 2nd parameter (and thus access the block id using $yourparamname->getVar( 'bid' ) from the block function).

PS: It's for 2.0.x... for 2.2.x the file to change is kernel/block.php
PS2: The feature requests trackers can be accessed by using the "Report core bug" on the left, then "Feature requests"

skalpa.>
Any intelligent fool can make things bigger, and more complex. It takes a touch of genius, a lot of courage, to move in the opposite direction.
Two things are infinite: the universe and human stupidity; and I'm not sure about the 1st one (A.Einstein)



10
skalpa
Re: Xoops Local File Inclusion Vulnerabilities
  • 2006/5/22 21:00

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


A patch will be published during the night (in 6-7 hours).

In the meantime if your server is endangered, you can apply the fix manually...

- Open mainfile.php
- Add the following lines around the end, just above the "if"
foreach (array('GLOBALS''_SESSION''HTTP_SESSION_VARS''_GET''HTTP_GET_VARS''_POST''HTTP_POST_VARS''_COOKIE''HTTP_COOKIE_VARS''_REQUEST''_SERVER''HTTP_SERVER_VARS''_ENV''HTTP_ENV_VARS''_FILES''HTTP_POST_FILES''xoopsDB''xoopsUser''xoopsUserId''xoopsUserGroups''xoopsUserIsAdmin''xoopsConfig''xoopsOption''xoopsModule''xoopsModuleConfig''xoopsRequestUri') as $bad_global) {
            if (isset(
$_REQUEST[$bad_global])) {
                
header('Location: '.XOOPS_URL.'/');
                exit();
            }
        }


So it looks like:
foreach (array(
.... 
CODE ABOVE....
}
    if (!isset(
$xoopsOption['nocommon']) && XOOPS_ROOT_PATH != '') {
        include 
XOOPS_ROOT_PATH."/include/common.php";
    }


PS: If you have the protector module installed then the snippet has to be inserted before the "precheck" include (nevertheless, a site with protector is shielded against this vulnerability).

skalpa.>
Any intelligent fool can make things bigger, and more complex. It takes a touch of genius, a lot of courage, to move in the opposite direction.
Two things are infinite: the universe and human stupidity; and I'm not sure about the 1st one (A.Einstein)




TopTop
(1) 2 3 4 ... 19 »



Login

Who's Online

108 user(s) are online (66 user(s) are browsing Support Forums)


Members: 0


Guests: 108


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits