iForum

Welcome Sudhaker !

• 2007/12/10 9:34:58
• marcan

A warm welcome to another great developer who has now joined our project : Sudhaker Raj !

Welcome my friend !

Re: A proposition for a true opened developement !

• 2007/12/10 9:13:42
• herko

Like I said in another post: SVN has a learning curve and requires specialised tools. Making a translation only requires a text editor. If there is a simple way to add and check language files, then I'd be ok with it. otherwise, this project is turning into a developers only project again, which isn't truly open IMHO.

Herko

Re: Auditing Code (security wise)

• 2007/12/10 8:37:44
• skenow

http://www.syhunt.com/section.php?id=checklist
http://www.owasp.org/index.php/PHP_Top_5

Re: A proposition for a true opened developement !

• 2007/12/10 7:50:09
• davidl2

It's a great idea - but scarey!

But I would suggest one change:

Have a "Live" branch which is the one where any issues and so forth are correct... and the "development" branch which any can contribute to.

The "Live" would always be a few days behind the "development" in order for errors to be reported and acted on...

A proposition for a true opened developement !

• 2007/12/10 7:43:32
• marcan

Sato-san brought the subject of the language files in another post, and it made me think about this.

I would like to see a lot more "integration" and "centralization" of code in the ImpressCMS project. I would like to see "more things" in "1 place" then everything spread around the internet.

In that regards, I would like to see the languages files as well as modules and themes all centralized in one location. Ideally SVN. But I know this would be a big change from the "XOOPS" way as it would require many people to have commit acces on SVN.

This might scare some people but not me. With SVN it is very easy to revert anything that needs to. So I do not see real problems with this...

And the more people we have on the SVN, the more quickly bugs will naturally be fixed.

So my suggestion would be to have new folders in our SVN :

- Languages
- Modules
- Themes

Then we provide everyone who requests it with commit access to our SVN so they can commit their modules, their language files, etc...

Maybe we need to think about the tree structure of our SVN, but the idea would be to have everything in one place, and give commit access to everyone who requests it.

A TRUE opened development. Everyone who wants to contribute will now be able to do so ! And if he does something very wrong, because we have many people using it, it will be reverted, fixed or improved quickly after.

Of course, we would have some mechanism to "eject" a user who is just playing dumb...

This would be a clear separation from the "XOOPS way", a clear statement of our true enforcement of our OPENED vision !

Now I know this will scare some of you, but let's discuss it

Rules to follow when using ImpressCMS SVN

• 2007/12/10 7:17:21
• marcan

Hi everyone, I would like to propose a few basic rules for all of us to follow when it comes to committing in the ImpressCMS SVN. This is a few rules I gattered from Dave_l post a few days ago.

1. Be informed of our discussions

Every developer need to stay informed of our discussions here. So we all need to make a commitment of reading everything that is posted on the Current and Future release forums. It is the only way we can all work together towards the same goal, and bringing synergy in our efforts.

2. Documenting our code

That means that every function has a phpDocumentor-compliant header comment, which is both correct and understandable, states the purpose of the function and describes the parameters and return value.

The same applies to class properties. The header comment for a function (or a class) is intended to be a "mini user manual" for the function that provides all the information needed to call that function, without having to examine the body of the function.

3. Use our trackers for nearly everything

Use the ImpressCMS trackers for everything you do. Bugs, Features, Tasks, everything.

For example, adding the Multilanguage features needs to have a task related. Same thing for the security audit or the removal of the XOOPS word all around.

4. Create 2-ways links

Create as many two-way links between Subversion changesets and ImpressCMS trackers as possible:

- In your commit message, refer to the tracker item ID.

- When you edit the tracker item on SourceForge, refer to the revision number of your commit in th SVN.

5. Commit logical changesets

When you commit a change to the repository, make sure your change reflects a single purpose: the fixing of a specific bug, the addition of a new feature, or some particular task. Your commit will create a new revision number which can forever be used as a "name" for the change.

6. About branching

We will use the "Branch-when-needed" system :

- Users commit their day-to-day work on /trunk.

- Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.

- Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.

- Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.

Thoughts ?

Remember me

• 2007/12/10 6:56:12
• sudhaker

There are number of hacks for "remember me" feature. Most famous is by GIJOE.

Can we extend this feature to have something what LinkedIn (and many other sites) already using.

* Once you login, you should have full access until session timeouts.
* After timeout, you have read-only access to your allowed contents.
* It prompts to login again if you want to do something transactional - say submit post.

Can we have built into new CORE?

Thanks,

Re: Using the trackers to document changes in the SVN

• 2007/12/10 6:40:44
• marcan

Ok good, we have started to use it. I saw others here have started to use it and I'm very glad !

Please document as much as possible everything you do with the tracker.

I also have another request. When one fixed a bug documented in the bug tracker, when you close the bug item, please post a message to document what you did, something like :
Quote:

Where XX us the revision number associated with your changes.

And of course, in your commit message, you would have written something like :
Quote:
That way, the bug and the fix are linked in 2 ways.

Any objection ?

Thanks !

Re: Auditing Code (security wise)

• 2007/12/10 5:46:00
• herko

Should we also review where queryf is used in key modules, as this is often misused by developers who want a quick way to access core tables.

Herko

Re: GoPHP5

• 2007/12/10 4:43:44
• Vaughan

and what about mysql5 too?

but in particular mysql5 has some functions that could be utilised (if used correctly, and that input is validated and sanitized before hand)

especially as mysql5 is able to use multiple queries in 1 session whereas mysql4 can only accept single queries at 1 time.. it could speed things up if multiple query ability is introduced.

I see someone has worked on adding mysqli support too, so even with mysqli, multiple queries can be utilised by the function mysqli_multi_query() instead of mysqli_query().

certainly something to look at tho either way.

Re: Auditing Code (security wise)

• 2007/12/10 4:04:17
• Vaughan

nice reading, very exhausting tho..

thanks for those dave & dave.

with regards to the conversation I had with Dave last night, it is apparent that the exit(); after redirect_header() is not required as redirect_header function is already terminated with exit(); in the function itself. I'll remove the extra exit(); in a bit for consistency.

my next task that I will look for is in the mysql query statements. In particular making sure that all values in the sql query itself are quoted '' regardless of datatype, this includes alphanumeric values aswell as integer values. this will help decrease SQLi attacks.

for example >

is very vulnerable (i am not ignoring sanitation here, but just the above is for example of why quotes are necessary)

in the above, if a user provides a value of "1 OR 1=2" the above query then becomes >



which means that an attacker could then retrieve an arbitrary row from the db bypassing the password itself.



I think maybe a good idea for me to keep using this thread to write down my intentions and explain the reasoning, + if anyone else would like to also offer suggestions, it's a good place to keep this discussion in 1 place.

Re: International (local?) support

• 2007/12/10 3:08:36
• davidl2

It's an interesting idea - it still doesn't stop local communities having a support site - but it does possibly remove the issues of their having to pay hosting etc.

I still say we should also have no objections if someone who operates a xoops site wants to support ICMS also... or if someone wants to run their site on their own server - but it would be nice to offer the option

Re: ImpressCMS Theme

• 2007/12/10 1:57:22
• studioc

james, looks great so far from the "view into source output". What I would add is a [html]label for the input(s).

after a quick look I ran into problems when the id of the single centercolums were assigned.

eg, I never get a "single-top-center-column" though both left and right centerblocks were not set. This is because the values are overwritten some lines below.

it is true that when both centerleft and centerright were empty normally this should be rendered as "single-top-center-column".

but, ... some lines below there is
<{elseif empty($xoops_clblocks) && !empty($xoops_ccblocks)}>
which is in this explecit situaton also true so the id of the centerblock will be rendered as "wide-top-right-column" only.

We can solve this situation copying the first block of lines (of the 3 blocks where the ids were assigned, not the blockoutput) below the 2 others (ctop centerblocks related)

So we get this instead:

<{if empty($xoops_ccblocks) && empty($xoops_crblocks)}>
<{assign var='tclc' value='single-top-left-column'}>
<{elseif empty($xoops_ccblocks) && !empty($xoops_crblocks)}>
<{assign var='tclc' value='wide-top-left-column'}>
<{assign var='tcrc' value='wide-top-right-column'}>
<{elseif !empty($xoops_ccblocks) && empty($xoops_crblocks)}>
<{assign var='tclc' value='wide-top-left-column'}>
<{assign var='tccc' value='wide-top-center-column'}>
<{else}>
<{assign var='tclc' value='top-left-column'}>
<{/if}>

<{if empty($xoops_clblocks) && empty($xoops_ccblocks)}>
<{assign var='tcrc' value='single-top-right-column'}>
<{elseif empty($xoops_clblocks) && !empty($xoops_ccblocks)}>
<{assign var='tcrc' value='wide-top-right-column'}>
<{assign var='tccc' value='wide-top-center-column'}>
<{elseif !empty($xoops_clblocks) && empty($xoops_ccblocks)}>
<{assign var='tcrc' value='wide-top-right-column'}>
<{assign var='tclc' value='wide-top-left-column'}>
<{else}>
<{assign var='tcrc' value='top-right-column'}>
<{/if}>



<{if empty($xoops_clblocks) && empty($xoops_crblocks)}>
<{assign var='tccc' value='single-top-center-column'}>
<{elseif empty($xoops_clblocks) && !empty($xoops_crblocks)}>
<{assign var='tccc' value='wide-top-center-column'}>
<{assign var='tcrc' value='wide-top-right-column'}>
<{elseif !empty($xoops_clblocks) && empty($xoops_crblocks)}>
<{assign var='tccc' value='wide-top-center-column'}>
<{assign var='tclc' value='wide-top-left-column'}>
<{else}>
<{assign var='tccc' value='top-center-column'}>
<{/if}>


this works for me in this situation. Same counts for the bottom centerblocks.

Or is it only me stupid?


what i would like to see in the source were hr's to devide the sections more clearly. we may hide them or make the "not visible" but we may (a)buse them to clear (repair) some "module templates output errors" using clear:something.


this for now!
keep on good work my friend
michael

Re: german files in SVN?

• 2007/12/10 1:11:11
• davidl2

Slightly off topic: I spoke with a module developer the other day, who is working on a language file generation module - which could be very useful for translators

International (local?) support

• 2007/12/9 23:27:30
• herko

How to deal with support sites?

I'm asking all these questions because Impress gives us the opportunity to start anew, and to organise things differently without any legacy.

I was thinking. Wouldn't it be a good thing to concentrate all support activities in one place? If there would be one server where all localised support sites would be located, accessible thru a national domain and a subdomain of the main url (for instance: impresscms.nl and nl.impresscms.org)?
Why, you ask?
Well, not to control who gets to be Official and who doesn't.
Concentrating the support, and bringing it as close as possible to the main project, provides several advantages:
- the central organization can provide quality services (such as an up to date and secure codebase for all sites, free hosting),
- communication lines are short: it is easier to relay news to the support sites (and to organize the communications)
- availability and consistancy of the releases: everyone has the same releases, changes to codes are made centrally
- easier to collaborate and to share ideas, not just limited to a single support group but for the whole project
- continuity of local support: no competition between support sites

What do you think?

Herko

Re: german files in SVN?

• 2007/12/9 23:18:54
• herko

SVN has a big learning curve, while editing translations (language files) doesn't require one to be a developer with SVN skills. So I'm not sure if this is a good idea.

How to deal with translations is a more general issue. I'd prefer it if the language packs are provided separately, as it decreases the upload time for the files, and normally only one language is used anyway (multilang sites excluded of course, but there isn't a rock solid solution for that yet).
Also, I would prefer if a translation is checked by at least 2 people. This to improve the quality of the translation.
What are the guidelines for translations? how formal is the language, or how technical? I would love to go through the core language files to see if we can make it more user friendly, and create some language guidelines for translators.

Herko

Re: ImpressCMS Theme

• 2007/12/9 23:12:12
• studioc

i will have a deeper look at this.

Re: german files in SVN?

• 2007/12/9 22:05:05
• nekro

I think that it could be posible to have all the language packs in sourceforge...

Re: Auditing Code (security wise)

• 2007/12/9 18:24:26
• davidl2

Few utilities I've found:

http://developer.spikesource.com/projects/phpsecaudit/

http://www.dragoslungu.com/2007/10/30/pixy-is-a-free-php-code-audit-tool/

http://www.php-mag.net/magphpde/magphpde_news/psecom,id,27497,nodeid,5.html

http://www.darknet.org.uk/2007/11/skavenger-source-code-auditing-tool/

Re: german files in SVN?

• 2007/12/9 17:41:17
• davidl2

Where is the best location for language files?