CMS Made Simple Forums

calguy1000 wrote: and the bloat can be quite extensive for sites that are only english, only use a few features, and want a small package to download and install....

Have it done for support reasons some times ago and for current 1.3 too - provide on german/deutsch project in forge a version with en and de language strings only (3.05 MB instead 4.76 MB).

http://dev.cmsmadesimple.org/frs/downlo ... DE-1.3.zip

Maybe it would be helpful for some english users too ...

@calguy
Not sure, if it would be possible to do it like TinyMCE - main release contains only english strings and other language files could be downloaded separately.

calguy1000 wrote:

P.S. What I would love to see in 1.4 is... remove any trailing bloat from the package. Let's see. First off, it includes a lot of useless SQL drivers, then, documentation, plugins and language files for many libraries used in the core. Then, for whatever reason many files have executable flag (notably languages) for no reason. In fact none of them should.

I would tend to agree with you, however it's not quite so simple....  I've deleted the sqlite option from the installer for now, but I'm not going to delete the drivers for it, or any of the other drivers, or plugins, etc. so that advanced users at least have the 'option' of trying out other databases or options.... from time to time this occurs... As well, deleting the extra files that we don't need just tends to make the problem of support worse.. 

if an "advanced user" wants to try out some other database; they'd better know enough to download a "full" release that contains all the languages and db drivers, instead of a "cleaned up" english/mysql only one. eliminating the unused and/or unsupported db drivers from the distribution archive will reduce or eliminate the temptation some would have to "tinker" with that aspect of the system, not encourage it and thereby generating additional support requests.

one question i have is: do any of the unused (or 'unused-by-most') files found in the (current) distribution archive pose ANY sort of security risk.. whether it be a known vulnerability or something that hasn't been discovered or fixed yet? IMHO, if it ain't being used, if it serves absolutely no purpose whatsoever, the code shouldn't be there.. and should not be copied to publicly accessible locations.

the "bloat" (non english languages, db drivers other than mysql, and a few other irrelevant things) currently (in 1.3) comprises a bit more than 50% of the extracted size of the distribution archive and it keeps getting "worse" -- back around 1.04 it was closer to 2:1 (keep vs bloat).

once upon a time, the plan according to ted, was to remove all non-english languages from the distribution and create a method to install only the additional languages that are wanted (at install or via the back-end). is this still happening? this would take a good chunk of the bloat out while ALSO reducing the size of some patches which have contained more updated translations than actual updated code.

Well, by 'bloat' I primarily meant documentation, plugins and unused database drivers. No one really checked out every example and installation folders of third-party packages and they might contain unexploited security issues.

I understand that it is difficult to release a dozen of separate language releases, and that is why everything is packed up in a big package. Anyways, I think that it might be a worthy experiment to release a full and English-only versions and check how popular it would be. For example, I would download an English-only version, checkout updated Russian strings from SVN and add them if needed.

As of permissions your understanding is correct, normally it should not make any difference. But imagine that a website was hacked. A hacker would then overwrite language file with an +x bit with his binary, exploiting some bug, run it via `` or system command and gain full access to the system. So it's a good idea to remove +x bits when unneeded just to make things a big more difficult. IMHO.

Regarding hardening the default .htaccess file, it think it's a very good idea that will much strengthen default CMSMS installation without a lot of efforts. Remember, most of us won't go beyond the defaults and a good .htaccess file is a plus. I think it's worthy to add a bunch of order deny,allow deny from all for all directories which shouldn't be accessible via web for sure. So even if a bug is discovered later on it will be almost impossible to make advantage of it. Also it's questionable whether those directories should be listed in robots.txt any longer as currently it's commonly used by exploit scanners to identify which folders might contain sensitive data. I don't have a lot of time, but if I can help somehow please let me know and I will try to do my best to find some time.

Okay, I caved

I've created a couple of scripts to help in the release generation process..

1) create_cms_release.sh
    - does the svn export
    - cleans permissions (files are 644, directories 755)
    - generates the full package as a .tar.gz (currently 3.5Mb)
    - calls another script to generate language packs
      - this script extracts all of the language files for a specified language into a .tar.gz file in the
        destination directory, and then removes them from the source directory
    - generates the lite - english only package as a .tar.gz (currently 2.6Mb)
   
2) I've also gone through and cleaned up alot of the adodb_lite directory, there's probably a few more
    drivers I could get rid of, but many are gone, along with a few other directories and files that we
    don't need.

3) I've asked Ted to create script or something that'll take this output directory, and maybe a CHANGELOG
    file or something, and generate a release in the forge with all of the files.
    This should help take some of the pain out of release generation

I still have to handle diff geneeration in the script I generated, but that shouldn't be too tough.

@ZYV

So the first thing I do after downloading a package is to delete unneeded languages (OK, this should not be done because we all have different needs), then delete ADO SQL plugins for whatever except mySQL 4+, then remove documentation, samples and plugins for all core libraries and finally changing all permissions to 644 (rw-r-r-, right?) and throwing .htaccess with deny from all all over the place like in plugins folder etc.

Can you paste the .htaccess file you use here, so I can take a look at it... we may just do that too.
it'd just be a slight modification to my create release script.

I think mark  was telling me to put this here... seems to kinda fit... not a switcher CSS but just adding them while creating the pages... I know i could move faster if that was the case and with more flexablity... my 2cents

After installing and using the cataloger... I had an idea... it'd be realy cool and handy to have sub styleSheets like the  "Sub - Template" cataloger for pages... there are plenty of times I want parts of style sheet that span many templates but not all the pages of those templates.... just have it so you could add as many as you wish, like attaching to templates (granted I'd probly only use one at any given point but i could see a need for multibles)

this is easily solvable already.

Just create a new stylesheet with just the stuff for those special pages.

In the pages where you want the special stylesheet, add something like this to the metadata field: in your page template, (after the {metadata} section in the header) do something like this:

calguy1000 wrote:     - calls another script to generate language packs
(...)
    - generates the lite - english only package as a .tar.gz (currently 2.6Mb)

Lite main + optional language paks : I like this. Thanks.
Pierre

@jeremybass

I was thinking you may want to read the part about the alternative style sheets...

Oh my bad...
But although I did want that as well I was thinking that If we had a css blobs that we could add to a page, that I could be shoved in the compiled style sheet that ended up as stylesheet.php?templateid=20&mediatype... Just a thought... still want the alternant style sheets though

jeremyBass

To be honest calguy, I've never used the CMS module for style sheets. I can see this method could be of benefit to those who are not web developers, but then would not they be happy with the current situation?

Web developers will be happy creating a user defined tag or something to achieve their style sheet loading. I use a UDT and it's highly flexible and can allow for most eventualities - but you have to get your hand's dirty with code Plus I can then add my own style sheet switchers etc.

I never used the internal stylesheets for a variety of reasons.
1. Speed
2. Control over order
3. No alternative style sheets
4. Selective loading of style sheets depending on variables.

Hope this helps in the debate, I'm all for v2.0 with some nice consistent fast core modules

Russ

Russ

If you never use the internal stylesheet mechanism how do you edit your stylesheets?...

If you are doing it by FTPing them back and forth isn't that kind of slow?...

Can you please modify the RewriteConds in the .htaccess (http://svn.cmsmadesimple.org/svn/cmsmad ... access.txt) To be this...
Remove the [NC] (no case) flags from the two RewriteCond. They are not supported by mod_rewrite in this context and will generally cause apache to log two [warn] messages in the error_log for every page access!

See:
http://forum.cmsmadesimple.org/index.ph ... 737.0.html
http://dev.cmsmadesimple.org/tracker/in ... 6&atid=101

I just want to add... I am happy to submit patches for minor things such as the rewrite rules above. I've found a couple of very minor issues in the code so far that I am happy to help on. I am not experienced with SVN but need to learn it. Is there any where we can submit code patches for consideration? If yes, is there any documentation?

tinhat wrote: Is there any where we can submit code patches for consideration? If yes, is there any documentation?

http://dev.cmsmadesimple.org/docman/vie ... isesvn.htm
http://forum.cmsmadesimple.org/index.ph ... 712.0.html