Re: GoPHP5
- 2007/12/12 12:01:55
- Dave_L
Is there some way we can accurately measure how many people would be adversely affected?
Would a poll accomplish this?
-----
My web server runs PHP4, and it is not feasible for me to upgrade the server to PHP5, nor is it feasible for me to switch to another server that runs PHP5.
[ ] Yes (I need PHP4-compatibility)
[ ] No (I do not need PHP4-compatibility)
Re: GoPHP5
- 2007/12/12 11:39:01
- Bender
I would say start using php5 only stuff right from the beginning. Simply because this is a new start and then be upfront with on the front page. (that download box for the core system should mention in small text some requirements)
Seriously how many people are we really talking about that would not have access to php5 now?
Don´t go for the half-baken solution and limit the development to keep compatability to php4.
It will only bind additional ressource to fix things now with forced php4 compatability in the core and then in 8 months go back and rewrite it again the way you would actually do it already today if you could. There are better things you can do 8 months in the future.
Might sound a bit arrogant against those that are actually forced to php4 without the option to quickly change to php5 but truth to be told: They have a problem with their hoster and not impressCMS.
I personally could not name one person i know that would not have access to php5 with their hosting.
Just my 0.02 cents.
Re: A proposition for a true opened developement !
- 2007/12/12 11:01:59
- Dave_L
It sounds to me like branches and tasks are basically the same.
I propose using the structure suggested in Subversion Best Practices: /trunk, /branches, and /tags.
/trunk is for mainstream development.
/branches is for major or minor tasks, experimental changes, etc.
/tags is for snapshots, including releases.
Re: A proposition for a true opened developement !
- 2007/12/12 9:46:51
- marcan
A new task branch would be used to implement a feature or a fix that is bigger then just a quick fix or a new language constant (as example). For example, implementing the multilanguages would have needed a task. Then when tested, the change would have been merged in the trunk.
As for branches, it would be used for future releases. For example, when 0.5 is released, we could create a 0.6 branch and improve it. Then create some tasks branche for bigger changes or features, that we would then merge to the 0.6 branch. And when we are ready for a release, we merge 0.6 in the trunk.
And of course, SVN provide ways to tag some code for a specific release, so in all cases, a release would be taged as such.
But this is all just a proposition. I don't have the absolute knowledge here 
Re: Language files and translations
- 2007/12/12 7:40:02
- kurak_bu
Some time ago I thought about a kind of DMS-Document Management System.
Maybe eeping all lang files in this system would make it easier to supervise. What do you think?
Re: International (local?) support
- 2007/12/12 6:57:33
- kurak_bu
I can see a small differences between polish users :D
Re: Modules
- 2007/12/12 6:01:40
- picia05
I vote for modules in standard becouse simple user download icms look how it looks and what he get ? No modules ... look at joomla cms it has ;P
Re: International (local?) support
- 2007/12/12 5:32:53
- picia05
I would like to have support site on my own server in Poland some reasons:
1) site load is faster
2) full control
Re: Captcha in the login form???
- 2007/12/12 5:17:25
- debianus
I suppose that the use of captcha is not only for login form: comments, forums etc.
I am not a developer and I do not know what is the best way, but, please, make it easy and make it as option (It has not sense when only registered users can send comments).
Today captcha can be used in Xoops by:
1.- Security image module and hacks by DuGris
2.- Frameworks
3.- Rmcommon by BitC3R0
I have the three ways in a page a it is a madness: DuGris hack in comments, rmmcommon in npages module and Frameworks for cbb.
Re: International (local?) support
- 2007/12/12 4:44:03
- herko
Agreed. Central service provider, that inclused a fallback. And not mandatory nor official (I hate that term too).
Herko
Re: Generating random prefix during installation
- 2007/12/12 4:25:39
- TheRplima
Excuse me, have found the task created.
I will commit the SVN and update it.
Re: Captcha in the login form???
- 2007/12/12 4:16:20
- saganxis
Shall we use a script captcha done or have to write the code???
I saw here
that this script is used by others CMS to generate captcha. I'm not saying we have to use it, just want to know if we have to do this or use some good script that are around there...
Re: Generating random prefix during installation
- 2007/12/12 4:09:26
- TheRplima
Hi there.
I have this done and working. But i can't creat a new task in SF project.
How should I proceed?
I wait someone create the task and then commit to the SVN or commit to the SVN and then update the task?
Let me Know.
Rodrigo
Language files and translations
- 2007/12/12 3:46:48
- debianus
I have seen some changes in two core language files.
It would be great that the translators job would be esasy and quick. By this way we could offer the release in several languages and it will help to the project success. Well, it is possible opens original and modified files and use meld, kdiff etc and find the changes, but after the changes must be pasted in the translated files and translated too.
The best way is the easiest way.
There are three possibilities (if anyone has more ideas, fine):
1.- As Instant-Zero does: explains the changes in the language files
// Added in xxx release
2.- Make a text file explains the changes.
3.- Make a diff file.
My vote is for the first.
Re: International (local?) support
- 2007/12/12 3:18:13
- debianus
I agree with Herko´s proposal; it is really good. But we must not "close doors": impresscms offers those services as option, not as a duty. If a local support site prefers use its own servers, themes etc, it is fine.
About several local support sites for the same country, I believe that it would be a rare (and allowed) possibility. In fact, I would prefer, as example, all support spanish sites only in a site for all countries. I mean: local support sites for languages, not for countries. For example: "spanish support", not "Spain support" (spanish is spoken in over 20 countries). There is not "Great Britain support" and "USA support".
But, as Tom says, we must solve the "server goes down"; it would be an horrour that all impresscms sites were down at the same time.
Re: Modules
- 2007/12/12 1:19:59
- debianus
About the question there was a very interesting discussion in Xoops Core Dev Team
http://sourceforge.net/forum/forum.php?thread_id=1756785&forum_id=347994
I agree with the core devs that it would be a disadvantage that the modules will be in the release.
But we can offer module packages (in the way of Sato-San did) and the possibility of install modules in the instalation process (as 2.0.18 XT-XM).
But I believe that would be neccesary make test of the modules included in the packages with the core release.
Re: Modules
- 2007/12/12 1:05:01
- debianus
Yes, it is possible in 2.0.18 XT-XM
http://debianus.org/uploads/resized_pic_1_470f5c6ec4b5e.jpg
http://debianus.org/uploads/resized_pic_1_470f5c27593ce.jpg
ImpressCMS is a multi-language content management system for the web. It is community-built, an open source project and based on the common web technologies of PHP and MySQL.
More information
