I just downloaded the latest trial release of phpdock. After the initial demo, run which worked perfectly, I changed only a single phpdock.ini setting, DocumentRoot to a sample website I'm developing in php. One would think with a comment like "DocumentRoot is relative or absolute path to web root directory tree." that this should work with my own absolute directory, but all I can get from dock is the same demo screen it started with.

After having played with other absolute paths and even just other subfolders than "web", ex. "myweb", I can factually state that phpdock completely ignores this ini file property. You can therefore only have your app in the web subdirectory.

Not true....I'm running my app in a folder under the root. Here are my phpdock.ini config lines:

[HTTPClient]
InitialUrl=http://localhost:${HTTPServer:Listen}/CM/index.php
BlockPopups=0
DefaultDocument=.\web\CM\index.php

A little clarification: Dock is no different than any other server OS serving http/https....you have to have your docs under the server root.....

I'll keep by my statement until proven otherwise, phpdock takes no notice of the DocumentRoot ini file property. The fact that you can use InitialUrl to get something from another subfolder is completely beside the point. The point is there is a DocumentRoot property documented as being able to change the root folder of the HTTPServer to ANY directory (relative or absolute), which is a lie. There is therefore no point for this property to be in the ini file in the first place.

Your statement is also false, I can in fact change IIS and Apache to use ANY directory I please as the root for a web site. Dock is therefore not the norm, it is the rigid exception. Kudos for Nusphere's intentions for the DocumentRoot property, but it is very clear they never tested it (who knows if it is actually implemented).

PS: Just a suggestion, but a ini file is very archaic. Dock will work fine for 1 or 2 apps with their own subfolders below the install dir, but what if I have 50 apps? What if another developer and I both want to install Dock apps to the same machine and our subfolders are the same? Are we suppose to install 50 dock instances on the same machine as a workaround? An XML config file would be much better or even a scenario where one could fire up Dock with a CL parameter to the config file/key to used.

Ah, I don't want to get into a pissing match here, but we are clearly talking about two different things. I was referring to an Apache install as a web server on a dedicated box, not running on your home PC as a dev environement. Whether you can actually specify the folder in which you wish your web documents to be served is another issue. It is common practice to route all http/https requests to a 'common' root, but I understand what you're saying. As for an .ini being archaic, that may be so, but Apache and PHP have committed to this, and it seems that Dock is nothing more than a custom Apache compile (or something very similar).

Best of luck. I'll keep my mouth shut and just keep writing code.

Later ~ RLR

It seems that Dock is quite capable of launching a site outside of the hierarchal \dock\web structure:

[HTTPServer]
DocumentRoot=c:\FolderOtherThanDockRoot\MyWebSiteFiles
Listen=8001
Bind=localhost
DirectoryIndex=index.php index.html index.htm
WriteTimeout=15
EnableFastCgi=0

[HTTPClient]
;InitialUrl=http://localhost:${HTTPServer:Listen} // commented out
BlockPopups=0
;DefaultDocument= // commented out

[Jobs]
;1=http://localhost:${HTTPServer:Listen}/sample/conveter-service.php
;2=http://localhost:${HTTPServer:Listen}/job2.php

This launches the index.html (or .php) file in the absolute path specified in [HTTPServer], which is outside of the \PhpDock hierarchy.

Hope this helps with the single instance of launching your site. As for your hypothetical deployment of multiple instances of Dock on a single machine, I can think of ways around that, too.

Have a good one ~ Lee

P.S. I'll add one other note: I said earler that I thought Dock was just a custom compile of Apache as the server module (I have no basis for this opinion, just a feeling -- I may be wrong). You may wish to pass parameters in phpdock.ini that are typically found in httpd.conf and see if the results are rendered as you would expect under an Apache install. I haven't messed with it, but........

Ah, the commenting out of InitialURL did the trick. So it is the one or the other Thanks much.

As to if it is apache or not... I'll take a guess: I doubt it. It is easy to compile an application which displays an embedded IE, installs a listening port, fetches scripts, pass them to a command line php.exe and capture the php output back for the browser using IE and namespace handlers. This is what Dock does. The hard work is done by PHP in Dock's case. That said, at least in my scenario Dock does something. If it was dock=apache, Dock will not be any different than unzipping a preconfigured apache+php into a directory.... which, come to think on it, may be a better alternative than dock:

* Your app is simply launched using a URL shortcut which fires up the end-user's favorite browser
* Is more flexible
* Can optionally install as a service
* Can handle multiple websites
* Can run and operate on any port
* Has none of Dock's restrictions

Disadvantage: much bigger distro

Hmmm... I'll have to ponder this a bit. Thanks for the feedback though, the commenting out would have been last on my list of permutations

I'm a neophyte when it comes to distributing PHP-based scripts that are designed to operate as standalone apps on PCs. I would typically just code in one of the Visual products, but I had a project that had a very short TTL, so I went with PHP and:

"unzipping a preconfigured apache+php into a directory" -->> I actually created a custom little xampp install that handled some php.ini config changes and additional .dlls I needed. This ended up being a double-edged sword:

Disadvantage: much bigger distro -->> Yes, plus I never looked into controlling the window object and it's children, so I was left with the user launching the script in a browser window with all their stuff, i.e URL bar, pop-up blockers, et al. It has been such a hassle.

Additionally, there are the inherent problems associated with users installing a server OS on their PCs with the infinite number of configs out there. I've got it down to eight clicks and no user input, but they still manage to screw it up. I'm really hoping that Dock eliminates the issues I've had with my 'custom' distribution of Apache/PHP/MySQL.

One other thing you should know about Dock (and PhpEd, for that matter): NuSphere is distributing a version of libea32.dll tht causes problems when calling scripts recursively. It may be included in the latest release of PHP from PHP.net, I don't know. For me, this caused a HUGE problem with a script I distribute. It calls itself recursively and makes heavy use of cURL, and with the libea32.dll that comes in the box with NuSpere's products (PhpEd and PhpDock, anyway), the cgi handler (php-cgi.exe) was launching multiple instances and not closing the processes, causing a 'CGI/FastCGI' error and halting execution of the script. After MANY hours, I finally figured out the problem, slapped the correct libea32.dll in the right spot, and no more errors.....just a head's up. Even disabling FastCGI in Dock didn't fix it (that's why you saw the [EnableFastCgi=0] in my dock.ini).

Take care, and best of luck on your projects,

RLR

Kudos!

LovinItAll ... just interested in the libea32.dll issue you describe.

Just that I have an issue with my project where it is opening blank every so often and just staying that way .... or opening and seeming fine until a random AJAX call just hangs dock. If you wait for like ... 30 seconds to a minute, whatever it has been waiting for will clear and all the actions you attempted to make will flash on the screen.

Just wondering if this is related to the issue you describe? And if so, what is the 'right' libea32.dll?

Cheers

There are no issues with libea32.dll library that we distribute as a part of php.

We requested some tech info from LovinItAll, including crash dump and list of dlls loaded in to the crashing process, but still waiting for the reply.
He provided us with a little sample that loads google home page using curl. According to LovinItAll, this sample would crash php in 5 minutes or even sooner. We ran it for hours and it still works up to now and no problem happened.

It seems that his machine was (is) a bit screwed up and it is caused the problem.
Indeed, it's not too hard to screw a system up with openssl. It's sufficient to have even one of the two openssl dlls in your system32 directory (or any other directory the system have in the PATH environment variable). If you do this, all software that come with its own version of openssl dlls will not work stable. It's because software being compiled with one openssl can not work with another openssl version witout re-compiling. Different versions of openssl are known to be not binary-compatible.
To fix the problem it's absolutely necessary to _remove_ all copies of openssl libary from all directories listed in the PATH and from system32 in particular.

I know that some versions of 3rd party applications like thebatt, xampp do install openssl libraries namely libeay32.dll and ssleay32.dll into system32 directory. If you find them there, first thing you'd have to do is to try to find a newer distro or at least move the libraries into the application directory.

As of 0.9.8g binaries suggested by Lee, it is unsafe to replace them. Indeed, openssl API is not frozen and structures are varying from release to release. With bruteforce replace you may get new unexpected crashes, for example when the counterpart will try to use another cypher.
To get it safely replaced, you'd need to recompile whole the php sources, including all extensions that rely on openssl (php5ts, php_ldap, php_curl, php_openssl and so forth).

Summary: I'd highly recommend not to replace openssl. It works stable and otherwise is not proven.
Finally if openssl or any php extension is not stable, an appropriate place to submit the report would be http://www.openssl.org/support/ and http://bugs.php.net/

First of all, I'd highly appreciate if you try to find some more correct words.
Secondly, it is not a lie because this option works pretty good.
What might cause your problem is below (just first 5 reasons that I can think of in the first place):
-you edited wrong phpdock.ini located outside of the directory where you run phpdock.exe
-you renamed phpdock.exe but forgot to rename phpdock.ini
-you edited DocumentRoot line in a section, other than [HTTPServer]
-you have multiple [HTTPServer] sections in phpdock.ini
-you run Vista and you edited virtualized (shadow) copy of phpdock.ini. Since version 2.0, PhpDock is Vista-compatible application and does not see virtualized copies of the files (the files that vista creates for applications not compatible with vista)

Truly, I don't know what it was, I:
1. Installed the trial for the first time on a XP Pro machine
2. Ran the demo/trial dock site, closed the demo
3. Edit the DocumentRoot in the ini to my own site
4. Ran phpdock again. Same site as in step 2 was displayed
5. Repeated step 3 for a few other folders and got the same result as in 4.

PS: These were my exact steps, this was my only installation of dock, and I have only one ini, and only one section of each in the ini, and I've not renamed the exe.

It only started to worked when I commented out the InitialURL the next day (read: after a reboot) as suggested by LovingIt.

If I can take a stab at it, I would say it was probably due to some caching issue, i.e. either the IE embedded browser caching and/or phpexpress compiled code caching. You would know best which, dmitri

I'll stand by what I said though, i.e. that changing the ini according to the instructions in the ini may not necessarily give expected results immediately. All said and done, I'm still testing and happy I can change to another location now and will most probably buy a license shortly.