Quote:

It was already there in 2.0.x, but must have been changed if buggy now. I'll check this.

Thanks for the details

skalpa.>

Quote:

But that is not the way to think. Such a configuration is severely dangerous and lame, and you should not dare having to deal with such a hole.
Whatever happens, if other users can do this then I bet they can easily read mainfile.php and get your database password, so whatever you do will just be placebo measures.

There are many PHP or 3rd-party based solutions that allow to provide secure shared hosts, and that work well. If your hosting company doesn't want to use one of them, then I think you'd better give your money to other people.

skalpa.>

Quote:

Better ask the Smarty devs about this one. IMHO the original idea behind Smarty (making a compiler/code generator) got lost progressively with the arrival of new devs to the project, who changed it more into a traditionnal template engine.

Quote:

And I wonder if you'd better not take your time when reading documents, whether it's a manual or roadmap you seem to miss the point each time.
What are you talking about ? Where did you read about abstraction ? The document talks about modularity, simplicity and layering, not abstraction. If you had read correctly, you'd have seen we're not taking the direction that leads to an absctraction layer, but more to an application development / generation platform, one of our goals being actually to ensure genericity and abstraction does not lead to overhead in the runtime code.
So forgive me, but you're a bit off-topic pal...

skalpa.>

Implement your function as a Smarty compiler plug-in (they do exactly what you complain is missing).



Or something like this.... Read the corresponding part of the Smarty manual

skalpa.>

Another one:
- Copy your dump to your server (best to put it in a password protected folder)
- Paste the following content in a file, change tha variables (host, user, pwd....) and save it as 'import.php', in the same folder
- Access import.php with your browser
- Delete both files


Might not always work, but the fastest way if your hosting company allows the 'system' command.

skalpa.>

1) About "using smarty code in PHP"
Forget about it. Anyway, this is not your real problem, just a wrong solution

2)

First, I'd like to thank everybody for the support you're showing. It's really warmimg me up after having felt so bad during two days. I want to promise you again we'll do our best to go in the right direction, and ensure everybody is recognized, whatever his contribution is.

Quote:
Thanks a lot. I don't think we should assign tasks either, it's not the point. It's first about giving you CVS access so you can apply the bug fixes you made or have by yourself, without having to wait for us. This is how we all started. You'll also become a privilieged collaborator who we trust, and can ask about some of the problems we encounter.

Quote:
That means beating up mambo m8 LOL
More seriously, mambo is certainly not what we're aiming at. For sure, having good designers and prices would be nice, but IMO mambo is reproducing what XOOPS did a few years ago. In some time, they'll get a big monster that makes nice things but is a pain to maintain and debug. I'm more interested by things like Typo3 (except for the fact it is over-complex and cannot be easily understood by normal humans, which is the opposite of what we're trying), or ezPublish (Xoops and ez will soon be the 2 only PHP CMS I know of that generate their own classes, except I've pushed this quite further than them and have been building several features of our system on this idea).

skalpa.>
PS: I only have the "features list" to finish before the Xoopshere roadmap is ready (I though it would be necessary to detail this part more, after reading a few recent comments here. So it may not be coming tonight, but it's a matter of days too).

Several public and private discusssions we had lately with some of the most respectable members of our community made us think twice about our own behaviors and methods. Despite the best intentions, we had to recognize something was wrong, that we had to take action.
When we took over XOOPS development, this program was done by one single person. And today, in fact, nothing has changed. Mithrandir has taken the lead of the 2.x branch development to allow me to focus my efforts on the next major release of the core. But still, he works on his branch alone, as much as I do on mine.
I have to admit my expectations to see the XOOPS development process evolve naturally in the good direction were overly naive. I still believe open-source development can happen fluently, with people contributing regularly becoming members, taking the work of others whithout any more time to give to the project. But a program made by a single person cannot benefit from this dynamic: for this to work we need a team, from the very beginning.

As a result, I recently heard complains from developers saying their work were not taken into consideration, while actually the main purpose of XOOPS 2.2 is to incorporate as many community provided features and patches as possible. And when I asked Mithrandir about the reason of this, he answered me something I can only understand: "I don't have enough time to add all the patches by myself".

This is ridiculous ! On one side people who have shown us their value in the past are ready to help us, and on the other side we, who desesperately need such people, are already so submerged by tasks that we look like we're neglecting them.
I can only feel guilty for this. I know that, for the things to change, we have to be the ones who take action, not them. And I believe that, if we had to wait for these people to show us their frustation before acting, we made a fault. We should have been able to see this before, but haven't.

Showing our gratitude is really important for the success of such a project, and frustration what we have to avoid by all means. Therefore if feel I have to publicly apologize to these people, as much as I have to try to change this situation.

So, after talking to Mith, we decided to ask the following people to officially join the core development team, so they can help us build and enhance XOOPS more effectively as today:
- hervet
- marcan
- phppp

This isn't much, but one of the only way we have to show you we recognize your value. Also if you accept, I don't think it is going to change your life so much, for the moment: being part of our official team doesn't mean you're becoming slaves who will have to listen to our orders.
The only thing we're asking you is to bring what you feel able to, so at the end our users can benefit from it. There's no real rule. As I previously said, the 2.x branch is maintained alive so we can incorporate as many patches as we can, so the features list is not limited.

There are only two things I'll ask you, because they are quite important to me:
- Talk to each others. This is nobody's one man show. If you disagree with somebody about a point, then ask a third person to join the discussion. If that didn't solve it, then ask all the team to join. Most of the times, people showing good will, who want to find solutions together, will always manage to find one.
- Think about the people coming after you. This is the only reason why I'd be able to refuse an addition to the core. As contributors to an open-source project, you'll have to realise you're not alone, that the work you do will have to be used or modified by others. A feature whose implementation cannot be understood by anyone else than you, and that will be extremely difficult to maintain is a poisonned present you do to your teammates, and to our users. This is of the greatest importance... before functionnality must come maintainability. Keep things as simple as possible, and try to document your work.

I guess I'll have to stop here, as this post is long enough already, but we can talk more about this later.
I just hope the 3 of you will answer positively. In a few weeks (days) the first Xoosphere alpha release will be made,
allowing us to start working collectively on this branch too. We will need other people then, but the transition can only happen better if we're already used to work as a team, even little, if we started to get prepared.
I trust all of you of much as I trust Jan, and really think this would be a really good team, source of many good news for everybody here.

skalpa.>

I have to comment a few things here, because there's been a lot of nonsense in this thread.

But first, some information for people who wouldn't be aware of how things were in the past:
- XOOPS has never been made in a way I'd accept to call collective: Onokazu has always been almost alone
- People who have tried to work with him have left because of "human incompatibilities". If you look at the XOOPS source code, you'll see names you might not really know: buennagel, w4z004, mvandam... Everybody, with no exception, left because they thought working with him was impossible
- He always used to work privately, to release almost finished works. Mithrandir's XOOPS 2.1.0 is the really first early release in Xoops' history.

Now about the SF thread that has been quoted, and comments made to it:
- I don't think getting mad is incompatible with being an open-source developer. If I had to use a single word to describe what I believe being an OS dev means I'd use the word teacher, not hippy.
- If you read carefully, you'll see the real subject of this conflict was not security against anything. Saying we are not concerned about security is completely wrong (some research will show you I've adressed the two security warnings we had in less than 48hrs, each time)
- The difference of POV we had there is the one we have in general: it's a question of methodology. As I said it was not security against something, it was straight orders against explanations and communication ! Onokazu was adding a very restrictive function, I just tried to ask why, and had nothing more in return that "because he said so".
- The answer we were expecting was very simple. And the token system this thread was about has been implemented in Xoops, just after gijoe's post. Actually I have problems reading we're not concerned about security, considering the fact this patch has never been released to the japanese community which is still forced to use the highly vulnerable 2.0.9.2 version.
- This is not a cultural problem. This is not the result of some kind of anti-japanese feeling as I've read it on the japanese site. This issue is purely between individuals. gijoe has shown me once again that when you want to collaborate, language or culture is not such an issue. During the last year, I've talked to several members of the jp community (domifara, gijoe, tom_g3x...) who have real difficulties to express themselves in english. And we managed it. In fact I'd say I've managed to communicate more with those 3 people than I never could with onokazu, who I have only barely spoken to.

So, to people complaining about our way to work: what do you people propose to enhance things ? What do you think is wrong ?
The next major version of XOOPS will be redone from scratch, partly because we believe open-source is a design (that means that a program that has not been designed to be made collectively, cannot be easily enhanced / developed collectively. And this was the most important problem we had to face when taking on the XOOPS code) and because we wanted to change the actual situation. The final version is planned for the end of the year. However, the development roadmap will be published next week, and the first alpha release is expected before the end of the month (which means it will be a very early release, made more than 6 months before the final version). This will also be the first version of XOOPS released with a full technical documentation. As soon as possible, we'll do everything we can to make people participate / take care of specific parts, but it was not possible before (as I say in the roadmap: people cannot collaborate if they have nothing to work on... So at least the earliest works had to be done by a single person).
Considering how long this will take, we decided to release XOOPS 2.2 (and maybe 2.4) with only one objective: the next 2.x releases will be done to ensure community provided patches are added to the core, to show people we care about what they are doing. The 2.x branch is not frozen: everybody coming to us with patches or work will be heard.

So: what else do you want ? But please, tell us what you would like, not only what you dislike. We're trying our best, but it is not an easy task, and complaining is much easier than trying to find solutions.
Not so long ago, I and Mithrandir were no more than anybody participating in this thread: XOOPS users. We tried to help and give some of our time to Xoops. This is how we became "Xoops team members". If you want to do the same, then you're more than welcome. If the only thing you're able to do is criticize, then you can download "Mambo open-source", nobody is going to miss you here.
Actually, you don't imagine how happy this would make us to have someone else to work with. Mith and I are both complaining because we feel alone, because we'd prefer having somebody close to us. But nobody comes...
People are spitting on us, but not a single one is really helping us do all that work our community is expecting.
Somebody who tried to help or find solutions has the right to complain if he is not heard. People who never gave anything do not.

skalpa.>

Sessions don't expire exactly after the session expiration time. To prevent having to check all the sessions on each request, the garbage collection function is called with a limited probability (by default is has 1 chance out of ten to be called).
So if you're the last person to leave your office, but the first to come back the day after, it may not have been called yet. Thus, clicking on a link in your open browser window may "refresh" the session state, and prevent it to expire.

skalpa.>