1. 13 Nov, 2012 1 commit
  2. 11 Jan, 2012 1 commit
  3. 31 Aug, 2011 1 commit
  4. 23 Jun, 2011 1 commit
  5. 25 Nov, 2009 1 commit
  6. 10 Nov, 2009 1 commit
  7. 08 Apr, 2009 1 commit
  8. 03 Aug, 2007 1 commit
  9. 06 Feb, 2007 1 commit
  10. 05 Jul, 2006 1 commit
  11. 11 Jan, 2006 1 commit
  12. 06 Aug, 2005 1 commit
  13. 07 Dec, 2004 1 commit
  14. 03 Sep, 2004 1 commit
  15. 21 Jul, 2004 1 commit
  16. 12 Jul, 2004 2 commits
  17. 13 Jan, 2004 1 commit
  18. 12 Jan, 2004 1 commit
  19. 22 Mar, 2003 1 commit
  20. 10 Feb, 2003 1 commit
  21. 24 Jan, 2003 1 commit
  22. 10 Dec, 2002 1 commit
  23. 27 Aug, 2002 1 commit
  24. 26 Aug, 2002 2 commits
  25. 14 Aug, 2002 1 commit
  26. 07 May, 2002 1 commit
  27. 24 Apr, 2002 1 commit
  28. 12 Mar, 2002 1 commit
  29. 01 Dec, 2001 1 commit
  30. 14 Nov, 2001 1 commit
    • jake%acutex.net's avatar
      We don't really need to look for fragments that are pulled in by [% INCLUDE %]… · c7434093
      jake%acutex.net authored
      We don't really need to look for fragments that are pulled in by [% INCLUDE %] or [% PROCESS %].  While removing this code bit doesn't allow us to seperatly check that those fragments exist and compile, they'll be checked atomatically when the the template that wants them is run through the process() routine by the 004template.t test.  This issue was raised because bug 98707 introduced a [% BLOCK %] element and the syntax for using that is the same as for including a template fragment.
      c7434093
  31. 31 Oct, 2001 1 commit
  32. 20 Oct, 2001 1 commit
  33. 10 Oct, 2001 1 commit
  34. 07 Oct, 2001 3 commits
  35. 06 Oct, 2001 2 commits