| Author | Post |
|---|
_Steve_
Member
| Joined: | Wed Nov 16th, 2005 |
| Location: | |
| Posts: | 13 |
|
Posted: Tue Jan 10th, 2006 01:46 am |
|
Hi Keith,
It would be great if the include block feature could be smart enough to know the difference between a virtual include and a file include (maybe recognize that no leading slash is a file include). I realize you addressed this once by creating the userFolder (or something like that). But the way it is right now it is impossible to create just one template sitewide but have includes based on the directory that the SHTML file is contained.
Thanks,
Steve
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Tue Jan 10th, 2006 06:24 pm |
|
Steve
The userFolder can be deceptive. If a Site Wide user edits a file that has a userFolder includeblock the include edit will get written to the site's home folder because that is the base folder of that user. If the idea of the userFolder was to let Folder Restricted sally edit an include in sally's folder, then the Site Wide user will have saved the edit in the wrong folder.
So, let's try your idea instead :-)
Let's remove the forward slash in the includeblock value, like so:
<DIV includeblock="some.txt">
<!--#include file="some.txt" -->
</DIV> |
That will tell EditWrx that the include is in the same folder as the shtml (or php/asp) file. Any user who has access to http://domain.com/sally/index.shtml would save an edit to the include at http://domain.com/sally/some.txt. But, the same user could edit http://domain.com/template.shtml and get the edit written to http://domain.com/some.txt .
That change will be available on the 6.10.060111 update (Jan 11)
|
_Steve_
Member
| Joined: | Wed Nov 16th, 2005 |
| Location: | |
| Posts: | 13 |
|
Posted: Tue Jan 10th, 2006 06:35 pm |
|
Hi Keith,
That is perfect!! As long as you can still map outside of the folder by including a leading slash, which I am assuming you can with your fix?
This will save me a major hassle of creating individual templates for each subsection of a site that I am currently marking up... Thank you very much!!
Steve
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Tue Jan 10th, 2006 07:15 pm |
|
You'll be able to have both kinds of includes on the same page. Again, in sally folder if you have
<DIV includeblock="some.txt">
<!--#include file="some.txt" -->
</DIV>
<DIV includeblock="/some.txt">
<!--#include virtual="/some.txt" -->
</DIV> |
You get the some.txt in sally folder and the some.txt in the home folder, and the edits get written to the correct files.
|
_Steve_
Member
| Joined: | Wed Nov 16th, 2005 |
| Location: | |
| Posts: | 13 |
|
Posted: Tue Feb 28th, 2006 10:14 pm |
|
Hi Keith,
I have found another bug/feature depending on how you look at it. For me its a bug right now but would be a great feature if it worked as suggested below. I have a template in the common folder that uses both file and virtual includes.
In the common folder I have filler files that show up as a file include in the template while it is still in the common folder. What happens is that when a user saves the template into the target directory it also saves the included file which overwrites the real included file located in the target directory. In other words it not only saves the actual template but it also saves the included file(s).
My suggestion is to check and see if the included files exist in the target directory. If they do then do NOT allow editWrx to overwrite them; if they do not exist then create them based on the included files located in the common folder.
Thanks,
Steve
*Didn't mean to cross post, this is just more appropriate here. I will try and delete the other one.
Last edited on Tue Feb 28th, 2006 11:14 pm by _Steve_ |
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Sun Mar 5th, 2006 11:16 am |
|
_Steve_
I had to look at this a half a dozen times to figure out what and how to do this, but I think I've got it.
If, when doing a SaveAs from the common folder, do not overwrite any include files if they already exist.
That rule can apply to both sitewide and folder specific includes because a file being saved from the common folder would not have any changes to the sitewide include since files in the common filder can not be edited.
The changes will be in the 6.11.060305 update later today.
|
_Steve_
Member
| Joined: | Wed Nov 16th, 2005 |
| Location: | |
| Posts: | 13 |
|
Posted: Tue Mar 7th, 2006 01:46 am |
|
Keith,
I really appreciate your responsiveness! It seems to work as expected, but I haven't had a chance to test it thoroughly yet.
You used the term sitewide in your post, would that be the same as a "virtual include"?
So the behavior is that it checks for the existence of the file regardless of virtual include or file include... the file include behavior would use the path from the "Save As" action and the virtual include would use the path contained in the HTML includeblock statement? Right?
I am not sure that I understand this statement:
That rule can apply to both sitewide and folder specific includes because a file being saved from the common folder
would not have any changes to the sitewide include since files in the common filder can not be edited.
Best Regards,
Steve
After thinking about this a little bit more, the virtual include type of scenario is moot, there is no file to overwrite the original. It is a little confusing, I just need to play with your update and figure out if it does what I envisioned it to do. I'll let you know if I find anything wrong.
Last edited on Tue Mar 7th, 2006 01:53 am by _Steve_ |
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Tue Mar 7th, 2006 04:28 am |
|
<grin> yeah I had to think about it for a bit too.
I started coding so it would not overwrite just the file type include if it existed. I then realized it shouldn't overewrite any include, virtual or file type, if it exists when SavingAs from the common folder.
|
_Steve_
Member
| Joined: | Wed Nov 16th, 2005 |
| Location: | |
| Posts: | 13 |
|
Posted: Fri Jun 2nd, 2006 08:44 pm |
|
Keith,
I just noticed (the hard way) that this behavior of not writing over already existing files does not apply when saving a file from another folder other than the "common" folder. Is it possible to carry this behavior of checking to see if the file exists before copying the included files to the folder regardless of where you are saving from?
/common
/common/a.inc
/common/b.inc
/common/file1.shtml <<includes a.inc and b.inc
/folder1
/folder1/a.inc
/folder1/b.inc
/folder1/file2.shtml <<includes a.inc and b.inc
/folder2
<empty>
/folder3
/folder3/a.inc
/folder3/b.inc
/folder3/somefile.shtml
This is hard to put into words so I am making an example...
Case 1: If I save /common/file1.shtml into /folder2 it will save not only file1.shtml but also /common/a.inc and /common/b.inc which is great!! :)
Case 2: If I save /common/file1.shtml into /folder1 it will save the file but it will not overwrite the already existing a.inc and b.inc files in /folder1 which is great!! :)
Case 3: If I save /folder1/file2.shtml into /folder2 it will copy not only file2.shtml but also a.inc and b.inc which is great!! :)
Case 4: If I save /folder1/file2.shtml into /folder3 it will copy not only file2.shtml but also a.inc and b.inc overwriting the already existing ones that are in /folder3 this is BAAAAAD!! :(
Any way to fix the behavior in Case 4 so it checks if the included file already exists before saving the included files just like it does when saving from the common folder?
Thanks,
Steve Plant
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Sat Jun 10th, 2006 02:13 am |
|
That makes sense to me. I hope it also makes sense to everyone else who's using SaveAs to create files with includes.
So, let's prevent the include from being overwritten ONLY if the includeblock path is not a sitewide virtual path beginning with a slash (or coming from the common folder). Therefore, if the includeblock path reference begins in the same folder as the original file, an existing include by the same name in the same relative position for the new file will not be overwritten.
Update 6.11.060609.
|
_Steve_
Member
| Joined: | Wed Nov 16th, 2005 |
| Location: | |
| Posts: | 13 |
|
Posted: Sat Jun 10th, 2006 03:58 pm |
|
Keith,
You are the best!!
Steve
|
Current time is 11:17 pm | |
|
