Hello, when I went to a admin panel I saw a text: "System Options", just below "Control Panel Home".
Is it really necessary to have this text? Just asking, the less messages-the better in my opinion.
Protector recommends changing default prefix: xoops to a new one. Maybe it is worth adding a randomly generated prefix in installation ?
Fine, I'm on the damn IRC thingy now. Happy?
As far as I know, commit access for an SVN project repository at sourceforge.net is either on or off; it can't be directory-specific.
Something I ran into last night when discussing this post with another programmer friend of mine...
I don't know if XOOPS also allows remote POST to files. If so, can we look at restricting POST to local filesystem files. Simon (from OIOPublisher) is already looking at a method for WP. I'm sure we could adapt this to our needs.
Joined! Waiting for acceptance.
Joined
We should also consider MyBlogLog and Blog Catalog for our iCMS Blogs.
Good idea about the LinkedIn Group so this is a new group on Facebook :
http://www.facebook.com/group.php?gid=7395938599
Facebook and linkedin will be very nice tools to make people know about us !
There's some good tips on xoops-tips about moving the important data from mainfile.php outside of the root as well - combine this with random database name, random file name and so on - it'll help a lot.
Funny you should say this Wtravel.
I was going to make a suggestion that the install routine could also add xoops_safe_path - like GiJoe's modules use - during install.
For people who can't create an "external-from-main-directory" directory - in could be pointed to a httpdocs\ level directory.
I am not sure what changes to the installation files are planned for 0.5, but regarding security improvements I surely hope we can move the mainfile.php to a folder outside the web root. Using an additional crypt class could encrypt the DB password as well, so that if for some reason someone can see this file (within a company perhaps someone standing behind the programmer) they still cannot do anything with it.
Another desired feature related to this is the creation of a random DB prefix upon installation.
One of the default modules IMHO should be the Protector module. This has proved to be very useful in stopping attacks, even though it is not a guarantuee for stopping everything.
Are these security improvements already planned or is it still unassigned?
This is something we should look at someone -as it is a very useful module.
Yes - you are correct.
This does not appear to work.
You can not show the plugin-dot in you block.
What was the problem with the module?
I chose the minical block - and it displays fine?
I do not see why it should not work.
I'm attempting upload at my test site to see if perhaps this is related to other issues... like the resource-template change of GiJoes (now fixed in ICMS update)
XOOPS 2.0.x has a problem with the block "minical_ex" from pical (GiJoe).
http://xoops.peak.ne.jp/md/d3forum/index.php?post_id=9787
Could you in the future work with impresscms?
Dave: That's the reason I suggested the "Live" & "Dev" versions (I'm sure there's a better naming structure - but lets use this for now )
Basically "Live" svn would be available to "Core" devs only - but the "Dev" release would be available to anyone.
There would be a small delay of - for example - 3 days ... after this delay, any code which seemed to be suitable from "Dev" could move to Live.
Perhaps a Branch on "Dev" being made for every month?
Does this make sense? Or am I talking nonsense
Quote:
JMorris wrote:
I think there should be some form of content management that is native to the core. Perhaps a "page" functionality with native WYSIWYG. Also a set of classes that enable you to output a ordered listed of recent pages in either templates or blocks.
If we are going more in the direction of Community Management Software, then I don't think modules should be bundled with the core. Core devs could still work on Mod dev teams, take Marcan for instance, but I don't think modules should be packaged with the core.
Now, if it is decided we move more towards true Content Management, then I would retract the above statement about bundling modules. Provided the modules bundled pertained to content management. (news, document management, blog, etc).