Quote:
Could you please tell us what it was (maybe it can help somebody else in the future).

skalpa.>

Another one: check that persistent connections are not used (edit mainfile.php, find the line that defines XOOPS_DB_PCONNECT, and ensure the value is 0 and not 1).

skalpa.>

Quote:

This method works generally better than phpMyAdmin if you have a lot of data to import.
People without CLI/shell access to their server can also try to put the MySQL command in a php script:
- Put the sql dump as well as the following 'import.php' in the same folder
- Display the import.php file with your browser


skalpa.>

The "Undefined index" lines mean XOOPS is unable to retrieve the config data from the DB.
Quote:
It might come from here.
MySQL 4.0 and 4.1 are not fully compatible since the later changed/enhanced its support for different character sets.
I can't help you anymore, as I never encountered this (I run different MySQL locally, so my local sites use the same versions as the online ones), but somebody else may give a solution starting from this info (maybe: check if the program you use to export/transfer the db data has an option to handle this).

skalpa.>

It's due to the fact you use PHP 4.0 or 5.1, but doesn't mean anything (a "notice" is not the same as an "error").

Don't take care of it.

A future release will ensure these notices disappear.

skalpa.>

Faster: Look into include/version.php

skalpa.>

Hi and welcome here,

First, as it has been said already, XOOPS will be highly dependent on external parameters/software (but if you plan to make such a site, I guess you already have somebody who knows that close to you).

Now, to answer your questions about XOOPS by itself:

0. Considering your objective, use the latest 2.0.x version as your codebase. There will be a clear upgrade path from this version to the next one (2.4.0) and the 2.2.x releases are quite less scalable, so you'll get more comfortable by doing this.

2. I wouldn't say any particular part has scalability problems, however several ones can/must be enhanced so you can reach you goal.

- The boot sequence (things done or launched from include/common.php) is particularly sensitive to speed enhancements as it will be performed on each page request, even if it does not actually have main problems.
- The output generation layer will have to be refactored (ie: it actually generates useless DB queries that could be prevented).
- The output caching system will have to be greatly enhanced too. It will also be a main actor on such a website and the actual one, if not inefficient, is too limited to give you a good control of your site caching policy.

3. We'll be publishing our objectives for the next major release really soon (within days/next week): changing the parts I talk of will be part of our targets, so to demonstrate what I said is precisely what I/we intend to do ;). I guess you will want to follow what's happening here before mid-september (and after... ), and we can talk again about your project soon.
But again, the success of this will depend on your server configuration, as well as on these XOOPS enhancements.

skalpa.>

Quote:

No need to use XML-RPC for this... but it's one of our targets.

However, I'm not sure it can be achieved right now... one of the main objectives of 2.4 will be "to prepare the core so this kind of things can be done".
So normally it should be in the next one (2.6) features list, and if we're lucky it should even become possible in 2.4 (although in a limited way).

skalpa.>

Quote:

No... eval() like some other PHP functions is just potentially dangerous.
If you are sure the code you give to eval() is safe, there should be no problem.
However if you try to eval() external data, then people may be able to send malicious code to it

So: it is not always dangerous, but it can become a big hole if you do not take care of what you are doing.

skalpa.>

Quote:

Our XMLRPC class is not PHPXMLRPC, we use another implementation (which doesn't use eval).

It doesn't concern XOOPS...

skalpa.>