next »

[OpenGeek]

Why don't you take snippets and templates out of the manager (and maybe also out of the db) and let us edit them in our favourite code editor? I hate it anyway to use these textareas with no syntax colors and no ability to use tabulators etc. I'd really prefer to write snippet code in a normal php file and upload these via ftp. This might also solve that multiple edit-windows problem.

Because a content management system is a content repository that stores value-added data along with the content.  If you want to code php files, then just do it and you don't need a CMS.  But a CMS will always have the need for meta-data to associate to a physical content resource, be it a column in a table or a file on the filesystem.

[atma]

See the left side of this screenshot. The tabs are at the bottom here (and I kind like them there) but they could also go above the tree. Like Breda, I think I'd prefer this to the current accordian menu.

I agree with you. And if use accordion menu, make it possible to hide like east/west panels here

[jeremy]

Just update my SVN, ...I like where the new admin 'design' is going.

[Sylvaticus]

Just update my SVN, ...I like where the new admin 'design' is going.

For us no-SVS's, can you give us a screenshot? 

[AMDbuilder]

Just update my SVN, ...I like where the new admin 'design' is going.

For us no-SVS's, can you give us a screenshot? 

A working zip would be even nicer 

[smashingred]

Folks SVN is not complex. While it would be nice to be shipping zips SVN clients for windows and mac are easy to use. TortoiseSVN for Windows is free and easy to install and download SVN files and then access features of Subversion without installing SVN server. For windows there is Versions which is about as nice as it gets. There is also SmartSVN for Mac.

Subversion clients will let you make diffs and patches of SVn files and submit them for patching changes in development by review.

If you don't have an SVN client for your development/design environment I'd highly recommend getting one.

Cheers,

Jay

[AMDbuilder]

I agree SVN isn't all that complex, but I can't seam to get past this step:

From the command line, change your working directory to _build/ and execute the command "php transport.core.php". This process will take an extended period of time (100 to 250 seconds likely), so be patient. (Note: on Mac Mini (1.66Ghz Intel Core Duo with 2GB RAM) running the Leopard development environment as outlined below, this only takes 5-10 seconds.)

I'm using Windows XP running XAMPP and RapidSVN as I had some issues with TortoiseSVN.  If I can get past this part I should be good to go with just SVN.

AMDbuilder

[BobRay]

I agree SVN isn't all that complex, but I can't seam to get past this step:

From the command line, change your working directory to _build/ and execute the command "php transport.core.php". This process will take an extended period of time (100 to 250 seconds likely), so be patient. (Note: on Mac Mini (1.66Ghz Intel Core Duo with 2GB RAM) running the Leopard development environment as outlined below, this only takes 5-10 seconds.)

I'm using Windows XP running XAMPP and RapidSVN as I had some issues with TortoiseSVN.  If I can get past this part I should be good to go with just SVN.

AMDbuilder

There are two easy ways to do that one. If you have an editor with a built-in PHP engine (e.g. PhpED or Eclipse), you can just load _build/transport.core.php and click on "run." That's what I do.

As an alternative, create a batch file with just this line in it (I call it build.bat):

Code:

c:\xampp\php\php transport.core.php

Put it in the _build directory and execute it. On Vista, I have to shell out to the command line, navigate to the _build directory and then execute it -- I don't know why, but it doesn't seem to work from Explorer (I could put it in the path and add a cd/xampp/hdtocs/mysite/_build at the top, but I've been too lazy to do it).

Note that you won't see anything happening for some time. Early builds used to take about 1-2 minutes on my machine but for recent builds the command line version now takes about 9 minutes and doing it in PhpEd takes about 4 minutes. No idea why. You won't see any output at all until it's done.

It would probably be a good idea to add some output at the beginning: "Building . . . please be patient" and echoing a dot every now and then (I've put in that request on Jira).

[splittingred]

There are two easy ways to do that one. If you have an editor with a built-in PHP engine (e.g. PhpED or Eclipse), you can just load _build/transport.core.php and click on "run." That's what I do.

Or, you can do what I do, which is simply load up the file in the browser, assuming you're running it locally (as I am here under /modx/):

http://localhost/modx/_build/transport.core.php

And let it run. That easy.

[BobRay]

Or, you can do what I do, which is simply load up the file in the browser, assuming you're running it locally (as I am here under /modx/):

http://localhost/modx/_build/transport.core.php

And let it run. That easy.

LOL . . . that adds some weight to my Jira request. I tried that a long time ago and after a few minutes of looking at a blank screen with "Waiting for localhost . . ." in the status bar, I assumed it wasn't working and gave up. 

[AMDbuilder]

It looks like someone updated the SVN as this is what I just got:

[2009-02-07 00:58:23] (INFO @ /revo/_build/transport.core.php) Beginning build script processes...
[2009-02-07 00:58:23] (INFO @ /revo/_build/transport.core.php) Removed pre-existing core/ and core.transport.zip.
[2009-02-07 00:58:23] (INFO @ /revo/_build/transport.core.php) Core transport package created.
[2009-02-07 00:58:23] (INFO @ /revo/_build/transport.core.php) Default workspace packaged.
[2009-02-07 00:58:23] (INFO @ /revo/_build/transport.core.php) Packaged in MODx Web Transport Facility reference.
[2009-02-07 00:58:24] (INFO @ /revo/_build/transport.core.php) Packaged all modActions.
[2009-02-07 00:58:24] (INFO @ /revo/_build/transport.core.php) Packaged all modMenus.
[2009-02-07 00:58:24] (INFO @ /revo/_build/transport.core.php) Packaged all default modContentTypes.
[2009-02-07 00:58:24] (INFO @ /revo/_build/transport.core.php) Packaged in web context.
[2009-02-07 00:58:44] (INFO @ /revo/_build/transport.core.php) Packaged in mgr context.
[2009-02-07 00:58:44] (INFO @ /revo/_build/transport.core.php) Packaged in connectors.
[2009-02-07 00:58:45] (INFO @ /revo/_build/transport.core.php) Packaged all default events.
[2009-02-07 00:58:45] (INFO @ /revo/_build/transport.core.php) Packaged all default system settings.
[2009-02-07 00:58:45] (INFO @ /revo/_build/transport.core.php) Packaged all default context settings.
[2009-02-07 00:58:45] (INFO @ /revo/_build/transport.core.php) Packaged in default user groups.
[2009-02-07 00:58:45] (INFO @ /revo/_build/transport.core.php) Packaged in default roles Member and SuperUser.
[2009-02-07 00:58:45] (INFO @ /revo/_build/transport.core.php) Packaged in default access policies.
[2009-02-07 00:58:47] (INFO @ /revo/_build/transport.core.php) Packaged core lexicon entries and topics.
[2009-02-07 00:58:47] (INFO @ /revo/_build/transport.core.php) Packaged in default access context permissions.
[2009-02-07 00:58:47] (INFO @ /revo/_build/transport.core.php) Beginning to zip up transport package...
[2009-02-07 00:58:52] (INFO @ /revo/_build/transport.core.php) Transport zip created. Build script finished.

Execution time: 29.7240 s

I love my home server 
AMDbuilder

[BobRay]

One of my sites hangs after showing:

Beginning to zip up transport package...

My other sites are fine, but this one hangs there in every browser and every _build method.

I believe it's this line where things go south:

Code:

$packResults = $archive->create("{$path}{$this->signature}", PCLZIP_OPT_REMOVE_PATH, "{$path}");

On the problem site, an earlier build was aborted during a build so it's half-built. I'm pretty sure that's the problem.

Is there anything I can try before doing a new checkout?

[OpenGeek]

Check differences in the memory_limits.  PCLZIP does everything in memory which can take a lot.

BTW, I always build local and upload the packages.  I don't ever recommend running the _build stuff on an actual server.

[BobRay]

Check differences in the memory_limits.  PCLZIP does everything in memory which can take a lot.

BTW, I always build local and upload the packages.  I don't ever recommend running the _build stuff on an actual server.

I was using the term "site" loosely. They're all local. I'm sure the memory is OK (I think it's 256) because it's the same for all the installs and the others are fine.

I made the mistake of closing down the resident debug listener during the _build on this "site" and it crashed the _build. It has hung ever since then. Is there some way I can get back to a clean pre-_build state without doing a fresh checkout?

[shamblett]

I've found on one of my windows boxes that deleting any existing core.transport.zip files and core directories in packages before I run the transport.core.zip seems to make it happier with zipping the core up. It would occasionally fail in the zipping, I do this every time now and its been OK since. Why this should be I don't know, linux has never done this.

BTW why do we zip it anyway? Does the install not just unzip it into the packages directory as 'core' and use that for the actual install. I've often thought this may be a step we can do without for local/dev testing. A flag maybe?

[OpenGeek]

I've found on one of my windows boxes that deleting any existing core.transport.zip files and core directories in packages before I run the transport.core.zip seems to make it happier with zipping the core up. It would occasionally fail in the zipping, I do this every time now and its been OK since. Why this should be I don't know, linux has never done this.

The packaging system is not controlled by SVN, so yes, you should always delete the old zip and the old package directory (core/packages/core/) or you run the risk of zipping up old files that may have moved or been deleted.  The Ant build scripts do this automatically, and I thought the build script did so itself as well, but maybe not.

BTW why do we zip it anyway? Does the install not just unzip it into the packages directory as 'core' and use that for the actual install. I've often thought this may be a step we can do without for local/dev testing. A flag maybe?

The package contains the manifest for installation of all data and files.  Technically, unless you run the Ant build scripts (local or distribution), you are not truly testing properly.  JS compression and aggregation, important file token replacement, and build specific features are all part of the build system to produce a downloadable/usable distribution package.

The Ant build system will be soon replaced by a Phing build system (since most PHP developers would be more likely to work with Phing than Ant), but will retain hooks from Ant (for those who use Eclipse, this will provide smooth integration with Phing via Ant).

[shamblett]

Fair enough, thanks for the info

[BobRay]

You should always delete the old zip and the old package directory (core/packages/core/) or you run the risk of zipping up old files that may have moved or been deleted.  The Ant build scripts do this automatically, and I thought the build script did so itself as well, but maybe not.

The code to delete it is there and I can't see anything wrong with it, but it wouldn't surprise me if there's a permission problem on Vista.

I updated the _build code to report on this and it appears that core.transport.zip is deleted but the attempt to remove the core/ directory fails:

Code:

/* remove pre-existing package files and directory */
if (file_exists($packageDirectory . 'core.transport.zip')) {
    unlink($packageDirectory . 'core.transport.zip');
}
   if (file_exists($packageDirectory . 'core.transport.zip')) {
       $xpdo->log(XPDO_LOG_LEVEL_INFO,'Failed to Remove core.transport.zip.'); flush();
   } else {
       $xpdo->log(XPDO_LOG_LEVEL_INFO,'Removed core.transport.zip.'); flush();

   }
if (file_exists($packageDirectory . 'core') && is_dir($packageDirectory . 'core')) {
    $cacheManager->deleteTree($packageDirectory . 'core', true);
}

if (file_exists($packageDirectory . 'core') && is_dir($packageDirectory . 'core')) {
    $xpdo->log(XPDO_LOG_LEVEL_INFO,'Failed to remove pre-existing core/'); flush();
} else {
    $xpdo->log(XPDO_LOG_LEVEL_INFO,'Removed pre-existing core/'); flush();
}

Manually removing the core directory solved my hanging _build problem (thanks Shamblett!  )

It also dropped my typical _build time from 540 seconds to 25 seconds.