Zikula Community

• meatedTaint
  
  

  • Rank: Registered User
  • Registered: Sep 03, 2004
  • Last visit: Oct 21, 2009
  • Posts: 15

  Posted: Mar 08, 2005 - 01:23 PM

  I've been shuffling through the forums looking for support for my issue. I have set up NW and it works well--even more securely than I thought. I'm having one problem so far (and I read and re-read all the NW docs and page.php in an attempt to ensure I'm not just missing something simple). All references to images are replaced with text (seemingly the ALT tag text). Whether they are linked image tags, or not. Whether I use "image.jpg", "./image.jpg" "../images/image.jpg" or other relative linking (relative to the PN root as prescribed in the docs), etc. Is this common? Is there a configuration I'm missing?

  • 
  •  
• **unknown user**
  
  

  • Rank: Helper
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 676

  Posted: Mar 08, 2005 - 08:48 PM

  If it's replacing Image paths with Alt text, it's obviously doing something wrong. I can't seem to reproduce it though.
  If you have a sample of sourcecode which is affected, and how it looks from the browser after, which you could post, that might help. A link if you have it could be good too.
  
  If $FixLinks is on, as it is by default, all links will be converted to root-relative links to prevent them breaking. It does not convert links beginning in a slash as in src="/images/image.jpg", but will convert relative links like "../images/image.jpg" to say "/nuke/HTML/../images/image.png" (given the file is in /nuke/HTML).
  
  For more on NukeWrapper permissions and directory access under Apache, see this thread. I've yet to include it in the documentation.

  • 
  •  
• meatedTaint
  
  

  • Rank: Registered User
  • Registered: Sep 03, 2004
  • Last visit: Oct 21, 2009
  • Posts: 15

  Posted: Mar 09, 2005 - 03:28 PM

  Hi.
  
  Thanks for your reply. I followed some of your advice in that other thread (the ideas for the security through apache and adding unlikely directories to the $HTMLdirs array), and for some reason, it fixed the problem. So, I've already moved my static HTML content there, and am satisfied with that.
  
  Like I mentioned above (maybe not exactly enough, though), I actually was writing the HTML with an awareness of the $FixLinks and relative links issues. So, I tried changing the paths of the tag's source attribute to test various ways of describing the path, and the problem remained. However, since I fixed the problem, I'm just going to go with what I know now, but I did copy a single file back into the PN root and it still presents the problem (apparently, your script stops in the first directory it finds the file existing in, starting with the PNroot). I'll leave it there for a bit and PM you a link to the file so that you may check it out if you wish.
  
  FYI: I'm using Apache2 & PHP4 (both debian packages). I also attempted to utilize directives from the NW.htaccess file provided with your script package to send any request for .html .htm and .txt files to page.php via env vars, but enabling the rewrite engine through a .htaccess file seems to cause a 500 error every time. I'm not sure (as I'm relatively new to Apache2), but I think it might be that there's a newer method for enabling the rewrite mod (rather than through .htaccess or [httpd|apache2].conf). I'm going to check further into that issue since I'd like to not have to preface links with page.php.
  
  Again, thanks for a great script/mod. I appreciate your work and the time you spend checking these forums.

  • 
  •  
• **unknown user**
  
  

  • Rank: Helper
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 676

  Posted: Mar 09, 2005 - 09:08 PM

  From you PM, I've discovered it's a bug in NukeWrapper. Since I always tend to use subdirs for HTML content, and the site is installed in a subdir itself, the error wasn't obvious. But I can replicate it now and have fixed it, and will upload it later after some more tests.
  The problem occurs when the Nuke site is in the server root and the HTML file being linked is there too. There's a test to check if the linked file is in fact in the same directory, and it's supposed to NOT parse the links if it is (the only reason to parse the links is because links are relative to the main file- page.php - not the included file, so when they're in the same location, it won't matter). A small error of logic meant it still parsed it, and since the file is in the Root, which is /, the link became //filename.html which browsers don't like. Where the site is in a subdir, like in www.site.com/nuke/ the fact it was being parsed when it shouldn't wasn't obvious, as the link produced was /nuke/filename.html, and the link worked.

  • 
  •  
•  
•  

Users on-line

• bvdbos3,
• mazdev

This list is based on users active over the last 60 minutes.