Again, I'm coming back with this request. Would you see any serious problem in starting to use the trackers at SF ?
I know we are still discussion about what our long term objectives are and it would be better not to start coding before this is all decided. But altought I agree we need to decide all this sooner than later, but we already have enough of an idea about where we are going that we can start coding 0.5 version.
So, in order to get things organized and track what we are doing, it is essential we use the bug, feature and tasks tracker. It is the only way we can be efficient and productive.
ImpressCMS can be found in a few places now on the web and XOOPS.org has discussed it briefly, and so does frxoops. So it is not a secret anymore.
Was the language fix included?
Any new language differences?
Kurak (Docs team) has asked for the Polish flag to be included - and asked if this fix was included.
Also: I've attempted to update from the latest release, on my test site - but updating the system module attempts to update another module already listed.
I just added it
So the EasiestMultilanguage is now part of the core or ImpressCMS.
I have added a new preferences category in General Settings, called Multilanguage Settings. There your can turn on or off the multilanguage feature. It will be turned Off by default.
You can have a look at the attached file to see these settings. These are basically the settings that could be configured in easiestml.php, but now, webmaster can do it via or more friendly form.
1- In order to take care of the XOOPS preferences system, I add to move the inclusion of the eaisestml file from after the XOOPS_URL delcaration in mainfile.php to after the $config_handler creation in include/common.php.
I did not investigate the side effect of this. Can someone have a look at it ?
2- I add to create a record in config_category, and a few ones in config_items. We will need an upgrade script for this. Anyone have played with the previous XOOPS upgrade script ? Anyone could write it ?
Of course, your comments are always welcome !
My vote : from now all, in all new code we write, we can use all the power of PHP5 without caring about PHP 4 compatibility.
Let's believe in our conviction. We all know PHP 4 is dead. So why bother.
For a frequently modified file such as the changelog, a safety measure could be to lock the file before updating your working copy from the repository.
This wouldn't help with the case in which someone forgets to update before committing. But it would help in the following scenario:
1. Person X updates.
2. Person Y updates.
3. Person Y commits.
4. Person X commits.
If Y locked the changelog before doing the update, then X would be unable to commit the changelog. (I think that's how it works.)
Locks are only advisory. If someone locks a file and forgets about it, someone else can unlock it, but it requires an extra step.