Starting my revolution

OK guys,

I’ve finally started to look at revolution in earnest now mainly to increase my understanding of the new world order and to provide some testing feedback, so,

I’ve checked the build out of subversion, built/installed it as per the write up on the SVN site, downloaded the wayfinder component and installed this, downloaded the andreas01 template built and installed this, so I now have a front page to look at!

I intend to expand this mini site by building and adding components as I go, hopefully slowly building it into something like the demo site that comes with 0.9.6(thinks!could we use this for revo when finished?).

On the way I’m bound to come across bugs etc. I’ve just come across this one for example, when I go to re-edit my first page after its initial creation I get this when I save it :- ’document_err_unpublish_sitestart_dates’, this may be because I’ve set a published date or some such.

My point is what’s the best way to feed this info back to you? I don’t want to flood the forum with stuff like this, nor do I want raise a JIRA ticket for each bug like this one, whats the best way here?

Forum for questions; Jira when you know it’s a bug...

OK, I’ll probably use a mixture of both here, I’ll try and file JIRA tickets with potential solutions/lines of code where I think the bug is where I can, even if it raises a lot of bugs the fixer will have a starting point.

Thanks shamblett! We always need more hands on deck for Revo.

Ok guys, where in JIRA do you want bugs against the components in modx-components filed? I’m no JIRA expert and I can’t see s project for this.

Some of the components have projects. If it has a project, file it in its respective JIRA project.

If it doesn’t - file it under the ’Other MODx Add-Ons’ project.

Thanks!

What follows is a detailed log of an installation on my Fedora 7 dev platform, it shows what I actually found and had to do to get the install to proceed :-
It raises a few questions that I’d like input to before I start to file bugs here.

1. Checked out latest svn, revision 4428
2. Copied _build/build.config.sample.php to _build/build.config.php, edited to suit
3. Ran ’php transport.core.php’, took 14.883 secs on my system.
4. Loaded http://localhost/revolution/setup, first error, got this on the web page :-

FATAL ERROR: MODx Setup cannot continue.
Make sure your setup/templates/_compiled directory exists and is writable by the PHP process.

5, Fixed this, reloaded the page, got the first page, Englsh pre-selected Ok
6. Second page OK, pressed Next
7. Third page, left selections alone, ie ’New Installation’, ’Core packages unpacked...’, ’Files already in place...’ pressed Next
8. Fourth page, entered database parameters, pressed ’Test Connection;, OK, enteed administrator details, pressed Next.
9. Fifth page, left the 3 paths alone, pressed Next.
10. Sixth page, got the following :-

Installation Summary
Problems were detected. Please review the pre-installation test results below, correct the problems as directed, and then click Test again.
Checking PHP version: OK!
Checking if sessions are properly configured: OK!
Checking if core/cache directory exists: OK!
Checking if core/cache directory is writable: Failed!
Checking if core/export directory exists: OK!
Checking if core/export directory is writable: Failed!
Checking if core/packages directory exists: OK!
Checking if /var/www/html/revolution/ directory exists: OK!
Checking if /var/www/html/revolution/manager/ directory exists: OK!
Checking if /var/www/html/revolution/connectors/ directory exists: OK!
Checking if /var/www/html/revolution/ directory is writable: Failed!
Checking if /var/www/html/revolution/manager/ directory is writable: Failed!
Checking if /var/www/html/revolution/connectors/ directory is writable: Failed!
Checking if core/config/config.inc.php exists and is writable: Failed!

For new Linux/Unix installs, please create a blank file named config.inc.php in your MODx core config/ directory with permissions set to be writable by PHP.
Creating connection to the database: OK!
Checking table prefix `modx_`: OK!

Ok, fixed the above verbatim, ie applied write permission where stated Pressed ’Retry’, all Ok now. Pressed ’Install’.

11. Got a blank screen, nothing in the apache error log, access log looks OK.

On my windows box, except for the renaming of the config.inc.php file this was all OK and the install proceeded without further issue.
I have another dev area that I’m using to construct my demo site, this was also on linux and I got the same error, to progress this I simply made the whole hierarchy writable and the install completed OK. So, it looks as though there is a perms problem on linux somewhere that stops the install, I’ll look at this when I get chance and findout what its doing, I’ll file bugs as appropriate.

I’m slightly concerned at what needs write access here, it seems to be most of the installation, on 0.9.6 I could nail this down just to the /assets directory. I’d formed the impression from other posts that with the ability to specify paths here we could split this into writable/readable areas now, i.e. besides obvious security advantages of read only code/areas it also allows easier packaging of MODx using RPM say. I may be ahead of myself here. till I know what the prob is of course.

Quote from: shamblett at Nov 16, 2008, 02:04 PM

I’m slightly concerned at what needs write access here, it seems to be most of the installation, on 0.9.6 I could nail this down just to the /assets directory. I’d formed the impression from other posts that with the ability to specify paths here we could split this into writable/readable areas now, i.e. besides obvious security advantages of read only code/areas it also allows easier packaging of MODx using RPM say. I may be ahead of myself here. till I know what the prob is of course.

For advanced installs, everything does need to be writable, for the duration of the install only. This is because PHP is trying to write files as the user executing PHP, including files that have to be in the root directory. This files, once written can have permissions set back to read-only once install is completed. There is a lot of work to be done on the installer still, and there will be different installation experiences for each distribution of Revolution.

But in order to advance the features of MODx to be easier to use for the masses, there are some things that are going to be unavoidable. Having PHP get permission to write to the proper files is one of them. Perhaps we’ll distribute .bat and .sh files that can automatically handle setting and resetting permissions for installation.

OK, fixed the blank screen, the packages directory needs to be writable, see JIRA ticket MODX-512. With this in place the install is OK. Point 4 is covered on the ’Fresh Installation’ page in the docs section, but not on the ’Development and Testing Notes’ page that I was reading, maybe these could be commoned up somewhere.

OK, yes we could use scripts to reset these perms but some directories will need to be writable, ’packages’ for instance. Should we not supply paths for these so they can be located outside of the core?. For now I’ll reset all the perms back to read-only except for packages and see how I go.

Quote from: shamblett at Nov 18, 2008, 09:32 AM

OK, fixed the blank screen, the packages directory needs to be writable, see JIRA ticket MODX-512. With this in place the install is OK. Point 4 is covered on the ’Fresh Installation’ page in the docs section, but not on the ’Development and Testing Notes’ page that I was reading, maybe these could be commoned up somewhere.

Actually, this needs to go in the pre-install checks directly... we’ll get this reflected on the various wiki pages.

Quote from: shamblett at Nov 18, 2008, 09:32 AM

OK, yes we could use scripts to reset these perms but some directories will need to be writable, ’packages’ for instance. Should we not supply paths for these so they can be located outside of the core?. For now I’ll reset all the perms back to read-only except for packages and see how I go.

The core itself can already be located outside of the web root, so no, we won’t be supplying paths for these outside of the core. For instance, I am running a centralized core much like a PEAR application; it exists in a specific path outside the web root and the config.core.php in each context’s base directory configures the core location and config key that context is going use to connect to a specific Revo database. In this external, shared-core scenario, the core/packages directory is effectively a shared package installation/uninstallation area. This is how I will be running MODx Revolution in all my instances; it just makes the most sense to me, but not everyone will have that capability.