Ok the theme as been fixed. Thanks James.
There is a line in theme.html that refers to backend.php - this has been removed from the trunk because it requires Herve's news module to work.
And I understand now. Vaughan added the "exit;" in the original mainfile.php :
Ok found it.
mainfile.php, line 104, there is this :
Hi guys, I just updated sandbox of the trunk and nothing is working no more. Just blank page, no debug. I will look into it but if anyone has an idea, please join me in the ImpressCMS IRC Channel, which, by the way, I implore all dev to try and use as much as possible. Will make it easier to help each other.
Thanks !
Yes, the upgrade script need to be done and the MySQL edited. I'm on it
Marcan - I can't seem to get this to work?
I also prefer to use only PHP5 as Marc stated, but i would suggeste leave the first release support PHP4 and for the next major releases focus on PHP5 i have on my servers since months only PHP5 ;)
Thanks Herko, i had no probs with you in the past ;)
Here's the basic wireframe. I've tested this on IE 6/IE 7/FF 2/Safari 3/Opera 9 all on Windows XP SP2.
If others, on other operating systems could give it a spin and make sure it displays correctly, that would be appreciated.
I figure, the base code we're working on for the iCMS homepage could be the basis for the first new default theme, so I'm throwing in all the block positions initially.
Ana, could you contact me via MSN? I need to talk with you about the graphics. Thanks!
Yes, yes, yes!
There are many tools that may assist us in this effort
* http://phpsec.org/projects/phpsecinfo/index.html
* http://www.nessus.org/nessus/
* http://www.security-database.com/toolswatch/PHP-Security-Scanner-1-2-added-to.html
I am not skilled enough in PHP or JS to spot vulnerabilities, so I can only start with tools like these.
just done a quick audit myself.
well i say quick, but it actually took me well over 2 hrs to complete, and that was only a very basic audit looking for 1 particular issue.
issue i have dealt with today is to make sure that header redirects 'header() & redirect_header' are all exited properly with exit();
not an issue for browsers etc, but if the pages were to be viewed via say telnet then it could become an issue as telnet does not understand header functions, so essentially the header redirect is ignored and the rest of the page will be continued on. exiting the script with exit(); after each redirect will prevent that from happening. it protects from those systems like telnet that don't understand the header redirect function.
nothing tedious, just a simple check.
i'll continue with this as i go along, obviously the more complex coding and vulnerabilities will be beyond my knowledge, but for those that i know about, i'll fix as i go.
Yup, a warm welcome from me too. Pred, I'm not managing this project, so you should feel more at home now
Herko
Wow,.I neglactic one day of viewing this forum and already there is more good news,.Welcome predator, I'm sure I/we will enjoy your presence/skills/views. Yep,.I'm happy;)
I'd love to see this option configurable in the admin and also as Dave suggested within the users profile so they can set how they want the date to appear for them personally.
I would also like to avoid what some modules do which allow the date to be set in admin, and that is to simply say to the user go to php.net and figure it out yourself.
Although it's relatively easy to figure out, our CMS targets people who sometimes don't wish to learn php, settings or variables, a cms system is to make it easier to publish information. So with that in mind an admin setting perhaps with a drop down box choosing how it should be displayed.
Or at minimum a simple explanation of the php date settings rather than saying "go figure".
Line 24 of style.css: Comment out or remove the absolute positioning. The float: left; takes care of the positioning.
That is nice :D
I agree that the date/time format should be more easily configurable.
I think it should also be configurable by each user separately.
This may be getting off-topic, but a related issue is that the formatted date/time is constructed in a .php file, which has the side effect that cached blocks such as Recent Topics use the timezone of the last user who caused the block to get cached, rather than the timezone of the current user. It would be better for the .php file to only provide a timestamp to the template, which gets dynamically converted to a formatted date/time.