Topic: The new manager - looking for best practice solutions  (Read 28804 times)

Pages: 1 ... 7 8 [9]   Go Down

#161: 23-Jan-2009, 01:39 PM

Foundation

OpenGeek
MODx Co-Founder
Posts: 6,956

damn accurate caricatures...

WWW
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.
Jason Coward
MODx Co-Founder
xPDO Founder
CTO @ Collabpad
work productively.
work intelligently.
work together.
Light is just a vibration of a note too. Everything is. You've got to keep that in mind.
  Frank Zappa

#162: 26-Jan-2009, 11:34 PM

atma
Posts: 58

Born in USSR ☭

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
« Last Edit: 27-Jan-2009, 12:48 AM by atma »

#163: 5-Feb-2009, 02:57 PM

jeremy
Posts: 65

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

#164: 5-Feb-2009, 03:47 PM


Sylvaticus
Posts: 491

I think, therefor I am. But what I am, and why...?

WWW
Just update my SVN, ...I like where the new admin 'design' is going. Smiley
For us no-SVS's, can you give us a screenshot?  Cheesy

#165: 5-Feb-2009, 03:50 PM


AMDbuilder
Posts: 726

WWW
Just update my SVN, ...I like where the new admin 'design' is going. Smiley
For us no-SVS's, can you give us a screenshot?  Cheesy

A working zip would be even nicer  Roll Eyes
I got carried away by the MODx spirit and ended up with a few templates to go with my website.

Server: Apache 2.2.11 | MySQL 5.0.81 Community | PHP 5.2.6 | Go MODx!

#166: 5-Feb-2009, 07:45 PM

Administrator

smashingred
Posts: 1,422

Jay Gilmore

WWW
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

#167: 5-Feb-2009, 08:09 PM


AMDbuilder
Posts: 726

WWW
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
I got carried away by the MODx spirit and ended up with a few templates to go with my website.

Server: Apache 2.2.11 | MySQL 5.0.81 Community | PHP 5.2.6 | Go MODx!

#168: 5-Feb-2009, 10:18 PM

Coding Team

BobRay
Posts: 5,356

WWW
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).
MODx info for newbies: http://bobsguides.com/MODx.html

#169: 5-Feb-2009, 10:22 PM

Moderator

splittingred
Posts: 1,512

i am alt-country rock

WWW
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.
shaun mccormick | modx foundation
modx revolution | jira bugtracker | official docs | svn tracker | api docs

#170: 5-Feb-2009, 11:03 PM

Coding Team

BobRay
Posts: 5,356

WWW
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.  Embarrassed
MODx info for newbies: http://bobsguides.com/MODx.html

#171: 7-Feb-2009, 12:00 AM


AMDbuilder
Posts: 726

WWW
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  Grin
AMDbuilder
I got carried away by the MODx spirit and ended up with a few templates to go with my website.

Server: Apache 2.2.11 | MySQL 5.0.81 Community | PHP 5.2.6 | Go MODx!

#172: 7-Feb-2009, 03:57 PM

Coding Team

BobRay
Posts: 5,356

WWW
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?
MODx info for newbies: http://bobsguides.com/MODx.html

#173: 7-Feb-2009, 05:18 PM

Foundation

OpenGeek
MODx Co-Founder
Posts: 6,956

damn accurate caricatures...

WWW
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.
Jason Coward
MODx Co-Founder
xPDO Founder
CTO @ Collabpad
work productively.
work intelligently.
work together.
Light is just a vibration of a note too. Everything is. You've got to keep that in mind.
  Frank Zappa

#174: 7-Feb-2009, 08:08 PM

Coding Team

BobRay
Posts: 5,356

WWW
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?

MODx info for newbies: http://bobsguides.com/MODx.html

#175: 8-Feb-2009, 03:18 AM


shamblett
Posts: 669

WWW
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?
Use MODx, or the cat gets it!

#176: 8-Feb-2009, 11:14 AM

Foundation

OpenGeek
MODx Co-Founder
Posts: 6,956

damn accurate caricatures...

WWW
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).
Jason Coward
MODx Co-Founder
xPDO Founder
CTO @ Collabpad
work productively.
work intelligently.
work together.
Light is just a vibration of a note too. Everything is. You've got to keep that in mind.
  Frank Zappa

#177: 8-Feb-2009, 12:24 PM


shamblett
Posts: 669

WWW
Fair enough, thanks for the info
Use MODx, or the cat gets it!

#178: 8-Feb-2009, 03:02 PM

Coding Team

BobRay
Posts: 5,356

WWW
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!  Grin)

It also dropped my typical _build time from 540 seconds to 25 seconds.
MODx info for newbies: http://bobsguides.com/MODx.html
Pages: 1 ... 7 8 [9]   Go Up
0 Members and 2 Guests are viewing this topic.