68 replies to this topic

[Arvy]

Good arguments, I subscribe to Peter's opinion.

I understood the reasons for the original suggestion and I've already implemented it. I just wanted to be sure that you (and any of your winbuilder.exe plans) were "on board" with setting something other than a numeric 'FALSE' equivalent as the default where the script file contains no value of its own. So long as you see no adverse functional implications, that's fine.

My change is lost that in WinBuilders Download tree the projects appear in the order of $subdir.

No, not lost. I have not forgotten your sort option request. It's just not implemented as the default in this update. In order to be consistent in both the browser view and in the .INI file output, the folder/file listings (both initial and subordinate) are sorted in the same order (PHP natcasesort) in both places. For the time being, you can hard code your own revision if you wish.

The upload error still exists.

I'll check again, but I can see no problem on either test installation. Did you also have an upload problem with v0.28? I didn't change anything at all in the FTP functionality -- at least not intentionally.

[pscEx]

No, not lost. I have not forgotten your sort option request. It's just not implemented as the default in this update. In order to be consistent in both the browser view and in the .INI file output, the folder/file listings (both initial and subordinate) are sorted in the same order (PHP natcasesort) in both places. For the time being, you can hard code your own revision if you wish.

I'll check again, but I can see no problem on either test installation. Did you also have an upload problem with v0.28? I didn't change anything at all in the FTP functionality -- at least not intentionally.

The order of $subdir is logically and therefore alpahetically 'unsorted'.
In my opinion this order in create_listing can only be reached by explicitely enumerating the folders:

if (!$update_list_all)

  {

	$subdir_count = count($subdir);

	for &#40;$i = 1; $i <= $subdir_count; $i++&#41;

	{

	  if &#40;in_array&#40;$subdir&#91;$i&#93;, $subInclude&#41;&#41;

		  $outputtext .= rtrim&#40;$subdir&#91;$i&#93;, &#39;/&#39;&#41;.&#34;=folder\n&#34;;

	}

  }

  else

  {

	$directories = directory_array&#40;&#39;.&#39;, FALSE, FALSE&#41;;

	natcasesort&#40;$directories&#41;;

	foreach&#40;$directories as $directory&#41;

	{

	  $outputtext .= clean_path&#40;$directory, 3&#41;.&#34;=folder\n&#34;;

	}

  }

The upload error I reported first when still using version 0.28

Peter

[Arvy]

The order of $subdir is logically and therefore alpahetically 'unsorted'.
In my opinion this order in create_listing can only be reached by explicitely enumerating the folders:

if (!$update_list_all)

  {

	$subdir_count = count($subdir);

	for &#40;$i = 1; $i <= $subdir_count; $i++&#41;

	{

	  if &#40;in_array&#40;$subdir&#91;$i&#93;, $subInclude&#41;&#41;

		  $outputtext .= rtrim&#40;$subdir&#91;$i&#93;, &#39;/&#39;&#41;.&#34;=folder\n&#34;;

	}

  }

  else

  {

	$directories = directory_array&#40;&#39;.&#39;, FALSE, FALSE&#41;;

	natcasesort&#40;$directories&#41;;

	foreach&#40;$directories as $directory&#41;

	{

	  $outputtext .= clean_path&#40;$directory, 3&#41;.&#34;=folder\n&#34;;

	}

  }

I'm not unaware of nor insensitive to your opinions, nor are they unwelcome, but, in the final analysis, I have to follow my own path of progession with a potentially larger audience in mind, at least some of whom may have their own various and differing views on this and many other things besides. I even have a few opinions of my own from time to time. And who knows? Nuno may have a few too. I can only promise that I'll do my best to accomodate eveyone in the long run.

There is no more $update_list_all config setting. But, if you change that top line to if(!in_array('*', $subInclude)) you'll probable have the variance that you want for now.

The upload error I reported first when still using version 0.28

Well, it has to be a problem of some kind with the set-up. If yours is anything like the browser.winbuilder.net subdomain, I strongly suspect that the $ftp_basedir (absolute path from the FTP login location to the base projects folder) is not just "/" like the $http_basedir is, and that supposition is also consistent with the error message. But, as I said earlier, only you can verify that.

[pscEx]

I'm not unaware of nor insensitive to your opinions, nor are they unwelcome, but, in the final analysis, I have to follow my own path of progession with a potentially larger audience in mind, at least some of whom may have their own various and differing views on this and many other things besides. I even have a few opinions of my own from time to time. And who knows? Nuno may have a few too. I can only promise that I'll do my best to accomodate eveyone in the long run.

I do not have any problem to make this small change on every new version.
But I think that currently there are three candidates who may want to have 'my' solution:
Two Vista projects appear as

• Tools
• Vista xxx

I think they would like to be seen as

• Vista
• Tools

And Unattended XP Install appears as

• LiveXP
• Tools
• Unattended

Maybe Nuno wants to see Tools at the end of his list.

There is no more $update_list_all config setting. But, if you change that top line to if(!in_array('*', $subInclude)) you'll probable have the variance that you want for now.

Thanks for the hint, I alreday changed. Makes the code less complicated.

Well, it has to be a problem of some kind with the set-up. If yours is anything like the browser.winbuilder.net subdomain, I strongly suspect that the $ftp_basedir (absolute path from the FTP login location to the base projects folder) is not just "/" like the $http_basedir is. But, as I said earlier, only you can verify that.

I found it:

$ftp_basedir='nativeex.boot-land.net/'; // WB projects directory absolute FTP path

 $http_basedir='/'; // WB projects directory absolute HTTP path

In the mean time I also understand the logic of the server

Overall current result:

Functionality including Upload, Delete, gen updates.ini works well for me!

Peter

[pscEx]

Real enhancement for me:

As known, I'm still working with the good old '.Link'.
Here the current WinBuilder update mechanism did not work.
I always had to

• Upload by FTP
• Calculate MD5
• Change updates.ini
• Download by FTP
• Edit
• Upload by FTP

Now: Browse in Arvy's management page to the destination, choose the file and CLICK
That's all

Peter

[Arvy]

I do not have any problem to make this small change on every new version.

Good grief, man, it won't be forever. One or two more revisions at most. In fact, I might even have it for you by later today. I just want to do it in a way that permits the widest range of options possible for various users.

But I think that currently there are three candidates who may want to have 'my' solution:

It sure would be nice to hear from them. We won't bite you in here, you know. And your suggestions, criticisms, whatever would be very welcome. Peter shouldn't have everything his own way exclusively.

Real enhancement for me:
As known, I'm still working with the good old '.Link'.
[...]
Now: Browse in Arvy's management page to the destination, choose the file and CLICK That's all.

Jeez, you mean I actually made somebody's life simpler. That really appeals to my own laziness.

[Arvy]

I might even have it for you by later today.

Okay, I "slipstreamed" something you can try if and when you want to. The config.php file adds a new setting:

$update_list_order = 1; // 0=unsorted, 1=browser order (natcasesort), 2=subdir array order

Just change the value from 1 to 2 for your preference.

I suppose the next thing you'll be asking for is FTP mkdir and rmdir capability. I'm looking at it, at least within each of the project subfolders.

[pscEx]

Okay, I "slipstreamed" something you can try if and when you want to. The config.php file adds a new setting:

$update_list_order = 1; // 0=unsorted, 1=browser order (natcasesort), 2=subdir array order

Just change the value from 1 to 2 for your preference.

I suppose the next thing you'll be asking for is FTP mkdir and rmdir capability. I'm looking at it, at least within each of the project subfolders.

Great! The code looks like that what I need . I'll try tomorrow.

Next question:
You seam to know me a bit now, but not good enough.
What I was thinking about was:

Upload a folder recursively
Update of updates.ini on upload (maybe this already exists, it's difficult for me to check)

Peter

[Arvy]

Upload a folder recursively
Update of updates.ini on upload (maybe this already exists, it's difficult for me to check)

Recursive uploading is a biggie. Probably not for a little while yet. The auto-update would be fairly easy, but right now you have to hit the update button. It's a fairly slow operation and, with people possibly uploading several files, it didn't make sense to slow down the process by updating automatically after each individual addition. It's certainly not out of the question if/when we do get to multiple batch uploads.

[pscEx]

Recursive uploading is a biggie. Probably not for a little while yet. The auto-update would be fairly easy, but right now you have to hit the update button. It's a fairly slow operation and, with people possibly uploading several files, it didn't make sense to slow down the process by updating automatically after each individual addition. It's certainly not out of the question if/when we do get to multiple batch uploads.

You know, English is not my native language. I gave your first sentence into a translator and got 'Das rekursive Hochladen ist ein biggie'

As you see, biggie is also unknown for the translator.
What is it? easy, difficult, nearly impossible, ...?

#2: The usual work is once a day / a week / a month upload a new version of a script. Then it would be nice (and not 'redundant') to have an automatic update of updates.ini.
The second usual work (rather seldom) is to deliver a complete project (see folder/recursive option). Then it is ok that at the end of upload some time is used to recreate the updates.ini.

But you are right: #2 is academic, currently really not necessary.

Peter

[Arvy]

Biggie [slang] = quite a major request, definitely not a trivial undertaking.

I'm under some constraints that Nuno imposed from the beginning (e.g., everything must be in one single PHP file) the reasons for which aren't entirely clear to me. But they don't make it any easier to accommodate many major features that might involve, for example, the use of well established PHP classes from external sources.

That is not to rule anything out. It just makes some things much more difficult to accomplish and recursive uploading would be a "biggie" in any case.

[pscEx]

Biggie = quite a major request, definitely not a trivial undertaking.

I'm under some constraints that Nuno imposed from the beginning (e.g., everything must be in one single PHP file) the reasons for which aren't entirely clear to me. But they don't make it any easier to accommodate many major features that might involve, for example, the use of well established PHP classes from external sources.

That is not to rule anything out. It just makes some things more difficult to accomplish.

Thanks for your explanation!

Due to what you devilered until now:

I think, that I'm the 'most complicated' provider. I have several projects in my server. As far as I know, all other providers have only one project (or they have different servers for different projects).

And as already stated before:

The current version of your prog gives me a lot of enhancements compared with the original WB functions.
BTW: I managed the different projects with a special system of mirroring on my PC. That's not necessary any more.

Peter

[Arvy]

Version 0.30 pre-release has been installed on both demo test servers for those who may wish to preview the functional changes there. They are as follows:
- Addition of FTP mkdir capability within projects subfolders
- Addition of FTP rmdir capabilty for empty subfolders only
- Left clicking on listed files opens new window (target="_blank" is non-W3C compliant, but W3C is just wrong on this one)
- Autologin option for anonymous user "on arrival" added to config.php (does not affect browsing control by administators)

On the VIRtech.org test site, autologin is set FALSE with limited anonymous browsing.
On the WinBuilder.net test site autologin is set TRUE with unrestricted anonymous browsing.

Version 0.30 is not yet packaged and available for public download. When it is, the top item in this thread will be revised accordingly.

[Arvy]

Version 0.30 is now available for public download and the top item in this thread has been revised accordingly. Please re-scan it for important notes that you may otherwise miss. The demo and download links are unchanged.

And, with that, I'm now counting the days until the ice leaves the Georgian Bay so that I can get my boat in the water again and cruise around its beautiful shoreline.

To all who have given your inputs to this effort, regardless of any particular views expressed pro or con, my sincere appreciation for your contributions. This was done for you, not me. I don't use it at all.

to everyone here.

[Brito]

Hi Arvy!

Version 0.30 is looking very good and usuable.

---

Regarding the Administrator mode, is it possible to:

- Allow file operations (move/delete/copy/rename)
- Upload a .zip file with automated unzipping
- Add a Configuration tab to set up default values (logo image, project title/description, homepage, etc)
- Remove the box for browsing projects (see red square on screenshot) as these functions are also available on the green squares



No hurries, just plain feedback and ideas.

[Arvy]

In other words, you want to know if it's possible to create a complete full-featured server site management package. Yes, of course it is. It has been done, both professionally ($$$) and by a few "freeware" enthusiasts (mostly organized groups over long periods) with complete site content management thrown in as well in some cases. Try CPanel, or if you're looking for a "freebie", try Xaraya, or Gossamer Threads.

But, if you're asking whether something like that can be compressed into one single PHP file with no database usage and customised for just a few specialised applications, the answer is no -- at least not by me, nor by anyone else that I've known or had any contact with. Considering any such undertaking under those kinds of constraints would be absurd. And be warned that not many of the "freebies" that are available use FTP for their file transactions. I knew of (and tested) one single CGI application that avoided PHP limitations, but it was dangerous to server security and I can't (won't) recommend it to anyone.

There are some things that my personal integrity just won't allow and compromising anyone's server security is one of them. The WB Browser that I provided in accordance with your specs allows as much optional administrative freedom as I'm prepared to build into a combined public browsing and server FTP access package, including the auto-login feature that I added in v0.30. Because it includes built-in FTP access, the task bar project selection is there in order to allow site administrators to decide exactly how "open" they're prepared to make it individually. It will remain so long as the combined features remain in a single-file package as far as I'm concerned.

Basically, v0.30 is a "dead end" from my prespective. It's underlying design parameters just don't give it a bright future as I see it and, as I've said elsewhere, wasting time (my own or others') is not my favourite hobby. I am, however, playing around with a few possibilties in my own idle moments. Peter (psc) is aware of some of them, but neither I nor they are ready to re-engage in any kind of public interaction on the basis of speculation and "toy" prototypes at this point. (Hint: Visit the demo/test installation on my VIRtech.org web site a few times over the next days and weeks.)

[Arvy]

Update for whomever it may concern.

For those (if anyone) who may be following the situation, the "toy" has now reached the prototype DBMS multi-site integration stage including some preliminary capabilty for data imports using the existing system. Emphasis remains, however, on the words "prototype" and "toy". There is no beta release and this is not an RFC call. Link.

[Brito]

I likely don't understand at the need for such worries about server side security as a professional on this sector would..

Nevertheless, what about topic #3 on the wishlist?

- Remove the box for browsing projects (see red square on screenshot) as these functions are also available on the green squares

Can it be removed?

[Arvy]

I likely don't understand at the need for such worries about server side security as a professional on this sector would..

What is it that you need to understand and don't? You asked for some PHP coding help with very specific parameters attached to your request and that's exactly what I provided. When requesting medical assistance, do you understand fully all of the medical procedures involved and do you insist on staying awake throughout and having them explained in ongoing lurid detail to ensure that your cardiac surgeon is using the "right" scalpel and holding it "correctly" while you "kibbitz" from the operating table and question his views on what's safe and what isn't for your own good health?

In your original request you said: "We need a developer capable of creating php script that can perform several features and functions that are very specific."

I've already explained the fundmental issues involved in those "very specific" parameters no less than three times since then. A single-file package designed to meet your specs (your original specs, that is, not the things you keep adding to them) involves certain security considerations. You may not understand all of them in detail, BUT you are not the only potential user and, AFAIK, the only person who actually is using it isn't complainig about too much site security. In any case, I WILL NOT deviate from the minimums that my own personal integity demands. Period. Full stop. End of FINAL explanation!!! I'm certainly not going to publish detailed "cracker advice" here or elsewhere for "script kiddies" to exploit.

Nevertheless, what about topic #3 on the wishlist? Can it be removed?

IT'S ALL ONE. It is integral to the whole package. Safe and secure coding is not bits and pieces that are tacked on at random here or there and can be removed at whim. You asked for both public browsing and administrative site managment to be included in one single-file package and that's what you got. The necessary elements are there as part of the package design to meet that request. They stay there. It's a dead issue as far as I'm concerned. Remove any part yourself at your own risk. Do whatever you want with it. It's all yours. I'm now working (more like playing actually) with something that corresponds with my own ideas and can do much more than a single-file browser package ever could if I fussed with its minor details forever and a day for the sake of mere arbitrary appearance issues.

I did what I agreed to do. WB Browser v0.30 is now YOURS! I'm done with it. Please take it away and bury it somewhere. From what I can understand, it's an orphan anyhow, or a single-parent child at best. And, based on my own follow-up discussions, even its one lone user seems willing to consider trading it in for something better and more suitable to the broader realities of the total "mission". I'm willing to accept that verdict on my own effort. Are you willing to do the same regarding what you specified in the first place??? --- That's a rhetorical question, BTW. It really doesn't matter whether either of us accepts it willingly or not. It's just a question of whether one will waste more time trying to "rescue" something beyond hope. I won't.

Instead of rehashing trivial ornamentation of a bygone failure (well, bygone for me at least) have you taken my "hint" to even glance at what I'm currently doing on my own? The admin login for the test installation is still "admin - admin". And, in view of your near obsession with appearance details, you might want to note, in particular, the « Modify Winbuilder Client Preferences » link at the bottom of the admin page -- a mere forerunner of what I have in mind.