rejetto forum
Software => HFS ~ HTTP File Server => Beta => Topic started by: rejetto on November 10, 2007, 04:56:21 AM
-
download @ www.dovedove.it/hfs/hfs142.exe
what's new
+ some improvements to the default template
- some folders were stuck on "replying" www.rejetto.com/forum/?topic=5154
- "open in browser" didn't work on some systems www.rejetto.com/forum/?topic=5159
- search results were incorrectly linked
- sort by hits was not applied to folders
- %item-ext% was not working with enabled "Hide file extension in listing"
- adding a file.lnk the virtual name was the one of the pointed file instead of the link itself
-
yay, The links for search results are working now.
-
We're the search results not working only on the default template? It worked fine on Terayon from what I saw.
-
thanks! :)
but what's this?
- adding a file.lnk the virtual name was the one of the pointed file instead of the link itself
-
We're the search results not working only on the default template?
The html version of search didn't work in any template. (incorrect path in results=file not found). There are threads that discussed this.
-
With #142, the default template (yes, i reset it) doesn't display correctly on my Firefox. No background, no icons, looks like crap. But IE7 displays correctly. (all done browsing localhost)
-
With #142, the default template (yes, i reset it) doesn't display correctly on my Firefox. No background, no icons, looks like crap. But IE7 displays correctly. (all done browsing localhost)
Idem for me, on Firefox.
Olivier
-
i found a workaround: edit the template, and remove the first line
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
anyone has an explanation for this?
-
Firefox is not compatible with the /~style thing. I tried that aswell with terayon a while ago :P
Try placing the style in an external file and you'll see it is working correctly
-
i found the problem: mime types
Firefox with that line, wants the mime type to be specified for the css file.
but mime types are not used for tpl sections.
the solution in next build is: mime types applied to section names, and the section renamed to style.css
-
i found a workaround: edit the template, and remove the first line
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
anyone has an explanation for this?
Works, thank you.
That's why betas are not for clueless people, such things can occour everytime.
-
Moved to 142 2.3 b and still can not open found file.
Edit: another cup of coffee did it ---> works great now !
-
Hello,
please go to Menu, Virtual File System and look that you have enabled Recursive Listing!
Greetings from Germany
-
Hello, please go to Menu, Virtual File System and look that you have enabled Recursive Listing!
Greetings from Germany
That's exactly it and that's why black coffee came in handy ;D
-
There isn't "up" link in the search results page. I need of this. Can it be fixed in the next build?
-
What do you mean "up" link?
-
There is nothing to 'up' to if you search in the root of the server, cause you are still in the root but you filter everything out.
-
-can i have one little cup of coffee pls?... :)
-why? ???
-just for coding, man! :P
-
Nice to see the search function finally :D
There seems to be some problems with it anyway:
Searching in root directory for *.avi or heroes for example lists almost all my files and folders. Searching for * returns even more items, pretty much all I think.
Searching in a subfolder works fine if I edit the template and change the form action='/' into action=''. Then I get correct results for the *.avi search for example...but not in root directory.
PS: How about moving the ".: Menu :." to the upper right corner...where the login used to be?
-
Nice to see the search function finally :D
There seems to be some problems with it anyway:
Searching in root directory for *.avi or heroes for example lists almost all my files and folders. Searching for * returns even more items, pretty much all I think.
Try searching for 'heroes*.avi'
-
Try searching for 'heroes*.avi'
No change what so ever... I get 3459 files - total: 10,73 GB.
With *.avi I get 3487 files - total: 23,30 GB
With heroes: 3465 files - total: 10,73 GB
With DSC01305.JPG: 3452 files - total: 8,34 GB
With asdasdasdd: 3452 files - total: 8,34 GB
With "buggy search": 3452 files - total: 8,34 GB
...so there's really no logic :D
On my other 2 PCs with b142 the search works perfectly in the root though... Same build, same template, same OS, pretty much the same software, same browser.
-
Hello, please go to Menu, Virtual File System and look that you have enabled Recursive Listing!
Greetings from Germany
That's exactly it and that's why black coffee came in handy ;D
hmm, i didn't think of it.
i guess that if recursive listing is disabled, search should be disabled too.
maybe with a warning when the user disables recursive listing.
is it ok?
-
Hello, please go to Menu, Virtual File System and look that you have enabled Recursive Listing!
Greetings from Germany
That's exactly it and that's why black coffee came in handy ;D
hmm, i didn't think of it.
i guess that if recursive listing is disabled, search should be disabled too.
maybe with a warning when the user disables recursive listing.
is it ok?
Yeah I think so. :)
-
On my other 2 PCs with b142 the search works perfectly in the root though... Same build, same template, same OS, pretty much the same software, same browser.
you are saying that the same HFS gives different results on localhost and over the network?
your vfs file may eventually be useful to understand your case.
Searching for * returns even more items, pretty much all I think.
ALL is exacty what * means.
Searching in a subfolder works fine if I edit the template and change the form action='/' into action=''. Then I get correct results for the *.avi search for example...but not in root directory.
searching in the folder only may come later.
PS: How about moving the ".: Menu :." to the upper right corner...where the login used to be?
i know you are used to that, but i think it is more visible on the left, and since it will contain almost all "features", it should not be missed.
-
A track for the deletion of files by the users is to force by hfs the suppresion of an uploaded file who has no size?
this will work only if option 'Number files on upload instead of overwriting' is disable
-
hfs #138
what's new
+ new URL parameters: filter, files-filter, folders-filter, page www.rejetto.com/forum/?topic=5073#msg1028672
?page=2&limit=20 doesnt work? It just shows the first 20 files.
Or am i missing a vital part now?
-
'page' fixed in next build
-
toSkip:=0;
if (conn = NIL) or (conn.data = NIL) then
data:=NIL
else
begin
data:=conn.data;
toSkip:=StrToIntDef(par('offset'), 0);
if limit < 0 then
limit:=StrToIntDef(par('limit'), -1);
if (toSkip = 0) and (limit > 0) then
toSkip:=StrToIntDef(par('offset'), 0)*limit;
end;
'page' can be resolved by this change
toSkip:=0;
if (conn = NIL) or (conn.data = NIL) then
data:=NIL
else
begin
data:=conn.data;
limit:=StrToIntDef(par('limit'), -1);
toSkip:=ifThen(data.params.IndexOf('offset') >= 0,StrToIntDef(par('offset'), 0);StrToIntDef(par('page'), 0)*limit);
end;
OFFSET is priority on PAGE ,
?offset=15&page=3&limit=6 will be result ?offset=15&limit=6
?page=3&limit=6 will be equiv to ?offset=18&limit=6
-
you are saying that the same HFS gives different results on localhost and over the network?
your vfs file may eventually be useful to understand your case.
No that's not what I ment. Anyway it turns out there's something wrong with my VFS file. I created a new one and the search worked with it. Could it be that there just was too much files & folders in the previous one so the search choked? I'll see if I could send you my VFS that is not working...
searching in the folder only may come later.
It's already possible when I just remove the "/" from the action=''...at least with Opera.
i know you are used to that, but i think it is more visible on the left, and since it will contain almost all "features", it should not be missed.
I don't think I'm used to it (I hardly ever use the Login button) but I think the menu shouldn't overlap with these texts:
folder
/Downloads/
UP
11 folders, 10 files - Total: 2,17 GB
...as it does now. What if you're f.ex. just about to click that "Folder archive" but you'd like to check what size the folder was with a quick glance...you can't because the menu is on top of it :D There's plenty of room for the menu and the search in the right corner..It looks empty now. The menu button also pushes the page contents even lower (being above the "folder" text), which does not look nice.
And also, the ".:" and ":." should not exist...
-
Could it be that there just was too much files & folders in the previous one so the search choked?
well, it is supposed to work anyway. :)
searching in the folder only may come later.
It's already possible when I just remove the "/" from the action=''...at least with Opera.
yes, i know it is easy. the point is to decide how to implement the choice at html level.
...as it does now. What if you're f.ex. just about to click that "Folder archive" but you'd like to check what size the folder was with a quick glance...you can't because the menu is on top of it :D There's plenty of room for the menu and the search in the right corner..It looks empty now. The menu button also pushes the page contents even lower (being above the "folder" text), which does not look nice.
consider the template in attachment
And also, the ".:" and ":." should not exist...
you don't like them eh?
-
i found the problem: mime types
Firefox with that line, wants the mime type to be specified for the css file.
but mime types are not used for tpl sections.
the solution in next build is: mime types applied to section names, and the section renamed to style.css
Hi! Thanks for great software, but even in #191 until I delete first line of default template i'm getting broken view of index page.
Please edit it for the next #192.