From: Jeff D. <da...@da...> - 2001-11-27 17:23:01
|
On Tue, 27 Nov 2001 02:11:46 -0500 "Carsten Klapp" <car...@ma...> wrote: > I tried to move some files in phpwiki but it isn't working as I expected. > Would you help? Sure. Glad to. The root of the problem, I think, is that CVS really doesn't support moving files. The only way to do it is to delete ("remove") the old file, and create ("add") a new one. (I'd guess that your CVS client is trying to be smart, and offering to fake the process for you --- but it's not smart enough to pull it off correctly...) (This also explains why the revision gets reset to 1.0. Don't worry about that --- it's unavoidable.) Try just "removing" the old file and "adding" the new one. ====== As for the changes you're making, I think generally they're fine ideas. I do have a few comments/suggestions, though: There are two sorts of files which need to be "found" during the execution of PhpWiki: 1. PHP source files (including non-PHP code which gets read by the PHP code like the templates, interwiki.map, pgsrc, and the entire locale subtree) 2. Files which need to be directly accessible via HTTP. The two sets do not overlap (except for index.php, sort of). It is somewhat dangerous, security-wise, to have the PHP source code directly accesible via HTTP, so it's best if things can be easily arranged to deny that. Currently (pre your changes) the only files which needed to be HTTP accessible were in the top PhpWiki install directory and in images. I think it would be best to keep these two classes of files in separate directories (as much as possible) specifically so that it's easier to administer, security-wise. (This would argue against putting the style sheets in the templates sub-tree.) > 2. Move nonessentials out of the root directory into a subdirectory > already known to wiki. We can eliminate the extra code for data_path vs. > virtual-path, and hopefully make it easier to use virtual paths. I think moving the style sheets into a subdirectory is a fine idea. (Perhaps the 'images' subdirectory should be renamed 'data' for this purpose.) (As a nit, I think the first theme should be called 'default' rather than 'vanilla'.) I don't think we can eliminate data_path vs virtual_path in all cases though. Not everyone has access to apache's Alias directive (it has to go in httpd.conf, and therefore requires root privs; and, not everyone runs on an apache server...) There are several other ways to get the "nice" URLs. Most involve being able to set DATA_PATH. > Alias /wiki3/ "/Library/WebServer/Documents/phpwiki-1. > 3/index.php/" > Alias /wiki3 "/Library/WebServer/Documents/phpwiki-1. > 3/index.php" Just as an aside: aren't these two lines redundant? I think if you have the latter, you don't need the former. (I haven't tested this though.) > Alias /wiki3admin/ > "/Library/WebServer/Documents/phpwiki-1.3/admin.php/" > Alias /wiki3admin > "/Library/WebServer/Documents/phpwiki-1.3/admin.php" (There is no admin.php in 1.3.) > - define(data_path..) and associated code is eliminated or reduced, now > resolves to Virtual_Path/templates. As I said, some people will still need DATA_PATH. I should rewrite the comments in index.php. I no longer use the SetHandler method (though it works). Here's what I do (assumes Apache with appropriate permissions): 1) Assuming /htdocs is the document root for the web server, install PhpWiki in e.g. /htdocs/phpwiki-1.3 2) Copy (or symlink) /htdocs/phpwiki-1.3/index.php to /htdocs/wiki. 3) Add the following to /htdocs/.htaccess: <Files wiki> SetHandler application/x-httpd-php </Files> (This tells apache that /htdocs/wiki is really a php script.) 4) Edit /htdocs/wiki: Set PHP's 'include_path' so that the rest of the PHP code can be found: ini_set('include_path', '/htdocs/phpwiki-1.3:/path/to/pear/code'); Set DATA_PATH so data can be found: define('DATA_PATH', '/phpwiki-1.3'); This method has the advantage, that one can run several different wikis sharing all the PhpWiki code. (E.g. copy /htdocs/wiki to /htdocs/wiki2. Edit $DBParams in wiki2 so that it uses a different database. Now you have two wikis running off the same code.) Another thing to keep in mind is that style-sheets will, in the future, probably become user selectable --- each wiki user can set in their preferences which style sheet they like best.... (Themes, as I understand them, will probably not be user selectable, but rather one will be chosen (then customized) by the wiki-admin when setting up the wiki.) (i.e. I foresee selection of style sheets will become somewhat orthogonal to selection of theme.) Also, think about how the theme selection is going to interact with the i18n support in PhpWiki. Currently templates are in locale/$LANG/templates for each of the supported non-english languages. (Currently all the non-english templates are severely broken --- but that's neither here nor there.... :-) Would it be best to do away with the templates in the locale subtree, and instead have each theme be language specific? E.g. there will be themes with names like 'default', (or 'vanilla'), 'default-de', 'default-sv', 'psychedelic', 'psychedelic-nl', etc. (The locale subtree would still contain the pgsrc and gettext stuff for the different languages.) ===== Having rambled through all this now, here's how I would refactor things: 1) Rename the 'images' subdirectory to 'data'. 2) Move phpwiki.css to data/default.css, phpwiki-heavy.css to data/default-heavy.css. If there are HTTP accessible files which are specific to certain themes, put them in appropriately named subdirectories of data. Wikibase.png, on the other hand, I would guess would be used by several themes, so I'm not sure it should go in a theme-specific subdirectory. 3) Move the theme specific parts of index.php into themes/<theme-name>.php. This would include pretty much everything in "Part Three" and "Part Four" of index.php. I'm assuming here that themes will be language specific --- otherwise the language config stuff should stay in index.php (or move to lang/<lang-name>.php?). 4) Templates for different themes would be in subdirectories templates/<theme-name>/. This does do away with your "one directory per theme" paradigm, which is attractive... (I've posted this note to phpwiki-talk too, as I'm sure others will have useful comments to make on the matter. If you're not subscribed to phpwiki-talk, you should be... http://lists.sourceforge.net/lists/listinfo/phpwiki-talk ) |
From: Adam S. <ad...@pe...> - 2001-11-27 17:44:32
|
> > Alias /wiki3/ "/Library/WebServer/Documents/phpwiki-1.3/index.php/" > > Alias /wiki3 "/Library/WebServer/Documents/phpwiki-1.3/index.php" > > Just as an aside: aren't these two lines redundant? I think if you > have the latter, you don't need the former. (I haven't tested this > though.) yep, you're right. > I should rewrite the comments in index.php. I no longer use the > SetHandler method (though it works). Here's what I do (assumes Apache > with appropriate permissions): i added this info the the /wiki wiki under the name PrettyWiki (sorry for the bad name choice, I'm at work and will ponder a proper name later). however i noticed two things: * the full text search is broken (i wanted to search to see if this info was already on the wiki) * numeric lists don't work properly i don't think. i think they should be more generous about continuing a list, otherwise listing technical docs like this is really hard (cause it keeps resetting to 1.). * it would be nice if ``WikiWord`` acted as a <tt></tt>. this was discussed a while ago. i believe the patch is trivial can we add it? i also think it would be nice if the monospace tags (leading whitespace and maybe ``) escaped automatic linking of WikiWords. i use monospace almost exclusively for technical snippets and having all the apache directives show up as links is annoying. finally and unrelated, could the patch you sent me to allow non-wiki word right had sides of interwiki links be included in cvs please? > This method has the advantage, that one can run several different > wikis sharing all the PhpWiki code. (E.g. copy /htdocs/wiki to > /htdocs/wiki2. Edit $DBParams in wiki2 so that it uses a different > database. Now you have two wikis running off the same code.) yah, i got three phpwiki's running on my server with this method. works good ;) adam. |
From: Jeff D. <da...@da...> - 2001-11-27 18:25:10
|
On Tue, 27 Nov 2001 09:44:29 -0800 (PST) "Adam Shand" <ad...@pe...> wrote: > i added this info the the /wiki wiki under the name PrettyWiki (sorry for > the bad name choice, I'm at work and will ponder a proper name later). > however i noticed two things: It's already (sort of) there in PageNamesInPathInfo. (Not that that's any better of a name.) > * the full text search is broken (i wanted to search to see if this info > was already on the wiki) Yes. I've fixed it in CVS, but the fix hasn't made it to the /wiki wiki yet. I'll work on it today. > * numeric lists don't work properly i don't think. i think they should > be more generous about continuing a list, otherwise listing technical > docs like this is really hard (cause it keeps resetting to 1.). You can't put blank lines between items. (A blank link starts a whole new <ol>.) PhpWiki has always been this way, I think. I don't like it either. The fix is not completely trivial, I think, so I've been putting it off (and, I think I'll continue to do so.) > * it would be nice if ``WikiWord`` acted as a <tt></tt>. this was > discussed a while ago. i believe the patch is trivial can we add it? > i also think it would be nice if the monospace tags (leading whitespace > and maybe ``) escaped automatic linking of WikiWords. i use monospace > almost exclusively for technical snippets and having all the apache > directives show up as links is annoying. What's the general concensus on this? (Yes, the patch is trivial.) Personally, I'm somewhat undecided. I would like the ability to include <tt> text inline. I'm not sure I like the syntax. (I don't like the backticks, and would rather see nearly any other character used for the escape.) (I'm not sure I like the current __ and '' syntax either, but it's kind of late to change that. If I had the chance to do it over again today, I think I would do (more or less UseMod style): Support <i>italic</i>, <b>bold</b>, <tt>fixed</tt>. Support also some e-mail heuristic style markup: *bold*, _italic_, etc. (In these cases the escape characters have to be properly nestled up to words: * bold * doesn't work, and there's no italics in a_packed_word.) At least that's what I think today. I think I'm against disabling WikiWord linkage within <tt>, though I do like UseMods <pre> and <nowiki> tags to help with that problem. > finally and unrelated, could the patch you sent me to allow non-wiki word > right had sides of interwiki links be included in cvs please? It's already there, I think. (In slightly modified form --- I've changed it so that the rhs can't contain punctuation.) Jeff |
From: Adam S. <ad...@pe...> - 2001-11-27 20:09:27
|
> It's already (sort of) there in PageNamesInPathInfo. (Not that that's > any better of a name.) ah, i figured it was there somewhere ... > Yes. I've fixed it in CVS, but the fix hasn't made it to the /wiki > wiki yet. I'll work on it today. great, thanks. > You can't put blank lines between items. (A blank link starts a whole > new <ol>.) PhpWiki has always been this way, I think. I don't like > it either. The fix is not completely trivial, I think, so I've been > putting it off (and, I think I'll continue to do so.) <laugh> ... okay. shame though it's awkward. > Personally, I'm somewhat undecided. I would like the ability to > include <tt> text inline. I'm not sure I like the syntax. (I don't > like the backticks, and would rather see nearly any other character > used for the escape.) there was some brief discussion, i believe the only reason it was chosen is that no one could think of anything else that was available. moin uses {{{text}}} which isn't great, i'm not sure what usemod uses. > (I'm not sure I like the current __ and '' syntax either, but it's > kind of late to change that. If I had the chance to do it over again > today, I think I would do (more or less UseMod style): > > Support <i>italic</i>, <b>bold</b>, <tt>fixed</tt>. > > Support also some e-mail heuristic style markup: > *bold*, _italic_, etc. i like /italic/ though i'm not sure if that conflicts with anything. is there any reason to support _underline_? or is that deemed confusing. i've certainly never missed it anyway. is it really too late? i think some of the wiki syntax phpwiki uses could be refined a lot. the alpha tree is already a large change, would some changes in hwo it works be possible or is that breaking too much backwards compatibility. > At least that's what I think today. i agree with you. > I think I'm against disabling WikiWord linkage within <tt>, though I do > like UseMods <pre> and <nowiki> tags to help with that problem. how come? in what situations do you want monospaced text and WikiWords? > It's already there, I think. (In slightly modified form --- I've > changed it so that the rhs can't contain punctuation.) great, thanks. adam. |
From: Jeff D. <da...@da...> - 2001-11-27 21:24:54
|
On Tue, 27 Nov 2001 12:09:22 -0800 (PST) "Adam Shand" <ad...@pe...> wrote: > there was some brief discussion, i believe the only reason it was chosen > is that no one could think of anything else that was available. moin uses > {{{text}}} which isn't great, i'm not sure what usemod uses. Ooph. {{{text}}} is ugly. Usemod supports <tt></tt>, <b></b>, <i></i>, <em></em>, <strong></strong>, and also supports the legacy ''italic'' and '''bold'''. I don't know if there are alternate forms for <tt> (I don't think so). > > (I'm not sure I like the current __ and '' syntax either, but it's > > kind of late to change that. If I had the chance to do it over again > > today, I think I would do (more or less UseMod style): > > > > Support <i>italic</i>, <b>bold</b>, <tt>fixed</tt>. > > > > Support also some e-mail heuristic style markup: > > *bold*, _italic_, etc. > > i like /italic/ though i'm not sure if that conflicts with anything. is > there any reason to support _underline_? or is that deemed confusing. > i've certainly never missed it anyway. > > is it really too late? Maybe not. I think the above syntaxes could be added without breaking the older syntaxes (at least not much), so we could have it all. > > I think I'm against disabling WikiWord linkage within <tt>, though I do > > like UseMods <pre> and <nowiki> tags to help with that problem. > > how come? in what situations do you want monospaced text and WikiWords? It's true that I can't imagine very many circumstances where one would want monospaced WikiWords. However, I think it's just plain confusing if italicizing and emboldening behave differently than monospacing. (Unless the markup gives more specific hints that other magic is going on, e.g. <code>ThisIsNotaWikiWord</code>.) |
From: Adam S. <ad...@pe...> - 2001-11-27 22:33:51
|
> Ooph. {{{text}}} is ugly. yep. maybe |text| or will that mess with table rendering? or >text< i'm just trying to think of what could be used. &text& or %text% none are particularly intuitive. at least ``text`` kinda fits in with past schemes though it also lends to confusion since most people are bad at spotting the differences and in fact some browser font rendering makes it almost impossible to tell the difference. > Usemod supports <tt></tt>, <b></b>, <i></i>, <em></em>, > <strong></strong>, and also supports the legacy ''italic'' and > '''bold'''. I don't know if there are alternate forms for <tt> (I > don't think so). that would work though i like not having to type html tags. another thought, i don't like the leading whitespace for mono-spaced text at all because it means that "^ *" doesn't begin a list and that's pretty confusing i think. if supporting <tt>text</tt> could mean doing away leading white space for mono that would be great and leading whitespace could stop being significant. > Maybe not. I think the above syntaxes could be added without breaking > the older syntaxes (at least not much), so we could have it all. maybe an option to activate old syntax and at some point make the new syntax standard? there's a lot of good thoughts on meatball about wiki syntax ... i think a lot of this stuff has evolved since wiki markup was first invented and certainly the purposes for which wiki's have used do to. another thing i'd really like is an alternate table syntax i stubled across on NiKki (a moin spin off). the way all the wiki's i know of renders tables gets *really* hard to maintain as tables get more complex. if you want an example check this page and edit it: http://www.personaltelco.net/index.cgi/Prism2Card i like the idea of treating tables like lists so you could make a table like this: * table heading ** row one *** column one *** column two ** row two *** etc ... i'm not sure of the exact syntax that NiKki uses and you'd have to make sure that it was able to tell teh difference between lists and tables, but i think it would be *much* nicer to maintain tables that way, and sometimes tables are the only way to effectively present data. on the prism2card page we started with lists and it was visually overwhelming and hard to find the information you wanted (let alone cross reference it with anything else). > It's true that I can't imagine very many circumstances where one would > want monospaced WikiWords. However, I think it's just plain confusing > if italicizing and emboldening behave differently than monospacing. > (Unless the markup gives more specific hints that other magic is going > on, e.g. <code>ThisIsNotaWikiWord</code>.) fair enough. maybe limited support for certain html tags would make sense then? adam. |
From: Carsten K. <car...@ma...> - 2001-11-28 18:54:11
|
Hi Jeff, You've raised some important issues which I didn't consider: security, rootless access and multiple wikis off the same codebase. -rootless access to server I agree, without root access to the server DATA_PATH will still be needed after all. -security Below is another folder layout which I believe takes these issues into consideration. Templates for all the various languages can still be grouped inside a locale folder within a theme, the whole /themes/default/locale/ folder could be excluded from server access. -selection of style sheets independent of themes -muliple style sheets can exist within /themes/default/, independent of language. Moving language specific stuff from index.php is a good idea too. The admin could then specify a default language and a theme and the wiki would be populated with the pgsrc from the default language, and the correct templates and text-messages would automatically be referenced. With this folder layout a new user preference could be added for the language, users could choose any one of the languages available in the current theme and the wiki dynamically serves out the appropriate system text, messages, and menus. Of course the page contents themselves would not change. Carsten /admin .htaccess DENY /docs .htaccess DENY /lib .htaccess DENY /locale (or /data/locale) .htaccess DENY /de /messages -phpwiki.php -phpwiki.mo /pgsrc -MeistBesucht -GuterStil -SeitenErzeugen -GaesteBuch -SeiteFinden -PhpWikiAdministration -WieManWikiBenutzt -SandKiste -PhpWiki -WikiTechnik -KonvertiereLeerzeichenZuTabs -EditiereText -TextFormatierungsRegeln -WabiSabi -WikiWikiWeb -StartSeite /en /messages /pgsrc /es /messages /pgsrc /it /messages /pgsrc /nl /messages /pgsrc /po /messages /pgsrc /sv /messages /pgsrc /schemas .htaccess DENY /tests .htaccess DENY /themes .htaccess ALLOW /default .htaccess ALLOW -default.php (php file here only to define variables for images, css names, and future: optional button graphics, logos etc.) -phpwiki.css -phpwiki-heavy.css -printer-color.css -printer-bw.css -largetext.css -handheld.css -wikibase.png -signature.png -themes.README /locale .htaccess DENY /de /templates -browse.html -editpage.html -message.html /en /templates /es /templates /it /templates /nl /templates /po /templates /sv /templates #eof |
From: Adam S. <ad...@pe...> - 2001-11-28 20:26:54
|
> /admin > .htaccess DENY one problem with this is you can't always rely on users being able to use .htaccess files. some isp's disable them on their web farms. i prefer to move all of my php code outside of my docroot (eg. /var/lib/ptpwiki-1.3.1). adam. |
From: Lawrence A. <la...@20...> - 2001-11-29 11:31:35
|
At 20:26 28/11/2001, Adam Shand wrote: > > /admin > > .htaccess DENY > >one problem with this is you can't always rely on users being able to use >.htaccess files. some isp's disable them on their web farms. > >i prefer to move all of my php code outside of my docroot (eg. >/var/lib/ptpwiki-1.3.1). > >adam. > Also, for some strange reason, not everyone runs Apache! Lawrence ps - am I sneding HTML emails? Sorry if I am - my client is playing up. Could someone let me know. Thanks ==========NOTICE========== Internet e-mail is not necessarily secure or reliable. Please let us know if you would like to establish a secure channel of communication. This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation. Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message. Tel: +44 (0)207 842 1200 http://www.20essexst.com pos...@20... |
From: Carsten K. <car...@ma...> - 2001-11-29 20:54:19
|
Good point, we can't rely on all servers using or isps allowing .htaccess files. As a side note, .htaccess files are used by Netscape Enterprise Server, NCSA httpd and I think Microsoft FrontPage Server Extension as well as Apache. Anyone else know about other servers? It might be helpful to include a couple of lines in the docs about security. Carsten On Thursday, November 29, 2001, at 06:31 am, Lawrence Akka wrote: > At 20:26 28/11/2001, Adam Shand wrote: > >> > /admin >> > .htaccess DENY >> >> one problem with this is you can't always rely on users being able to use >> .htaccess files. some isp's disable them on their web farms. >> >> i prefer to move all of my php code outside of my docroot (eg. >> /var/lib/ptpwiki-1.3.1). >> >> adam. >> > > > Also, for some strange reason, not everyone runs Apache! > |
From: Jeff D. <da...@da...> - 2001-11-28 19:45:24
|
On Tue, 27 Nov 2001 19:02:17 -0500 "Carsten Klapp" <car...@ma...> wrote: > -security > Below is another folder layout which I believe takes these issues into > consideration. Templates for all the various languages can still be > grouped inside a locale folder within a theme, the whole > /themes/default/locale/ folder could be excluded from server access. I think Lawrence's idea for embedding translatable strings in the templates is a great idea which will eliminate the need for having a separate template for each language. With that, you only need one version of each template for each theme (or even less? some themes may share templates). > -selection of style sheets independent of themes > -muliple style sheets can exist within /themes/default/, independent of > language. Here's another crackpot idea. Have the main phpwiki script (or another new php script) serve up the CSS stylesheets. I.e. all the templates link to the style sheet with: <link rel="stylesheet" href="index.php?action=css" type="text/css" /> When index.php is invoked with the action=css argument, it serves up the style sheet from the file themes/default/phpwiki.css (or possibly some other style sheet, depending on what the user has set in his preferences.) Advantages: o Direct web access to phpwiki.css is not required. o Actual wiki HTML is completely independent of what style sheet the user has selected in his preferences. (This might be a big win if we ever implement HTML caching, or if the wiki is served through a caching proxy.) Disadvantages: o Wierd? o Have to pay attention to the HTTP cache-control headers when we serve up the CSS, so that the browser doesn't have to reload it for every page view. (We should probably be paying more attention to the cache-control headers anyway...) > Moving language specific stuff from index.php is a good idea too. > [other good notes deleted] To rephrase your notes (which I deleted): There are basically two indepedent purposes for which we set language preferences. (Currently the config controls for these are all mangled into one...) 1) To select the initial pgsrc. Maybe we should fire up wikis with (perhaps selectable) pgsrc in multiple languages by default? 2) To select run-time (gettext) translations (and also things like date and time formats) (and currently also to select templates, though Lawrence's idea would eliminate that need altogether) Just rambling, I guess, sorry... More random comments on your proposed directory structure: > /admin > .htaccess DENY Admin seems mostly vestigal to me. Can we do away with it altogether? > /docs > .htaccess DENY We don't have this now. It's probably a good idea. I think 'doc' would be the more standard name. > /tests > .htaccess DENY tests/unit_test_backend_cvs.php currently need to be HTTP accessible to be used. > /themes > .htaccess ALLOW > /default > .htaccess ALLOW > -default.php If avoidable, this should not be HTTP accessible. (It would be an error to try to run it.) Also, since it's already in the themes/default subdirectory, why not name it config.php, instead of the redundant themes/default/default.php? > -phpwiki.css My crackpot idea (above) would make it so that this need not be HTTP accessible. > -wikibase.png Making the image files the only ones which still need to be directly HTTP accessible. Because of this I still think they ought to go somewhere else... > -themes.README Should go either in /themes or in /doc (or /), I would think. > /themes/locale Probably not needed once we make templates non-language-dependent? (Templates can go directly in /themes/default.) So, here would be my counter proposal (today, at least): /images (.htaccess ALLOW) - wikibase.png Leave images here. Get rid of /templates (& the templates in /locale) in favor of /themes (.htaccess DENY) /default -config.php -default.css -default-heavy.css -psychadelic.css ... -browse.html (or browse.tmpl)? ... /classic -config.php ... Jeff |
From: Jeff D. <da...@da...> - 2001-11-28 19:52:06
|
On Wed, 28 Nov 2001 11:45:13 -0800 "Jeff Dairiki" <da...@da...> wrote: > Here's another crackpot idea. Have the main phpwiki script (or another > new php script) serve up the CSS stylesheets. ... > Advantages: One more, that I just thought of: the script can serve different style sheets depending not only on user preference but also depending on User-Agent. This would eliminate the need for the "@import url(phpwiki-heavy.css);" hack. |
From: Carsten K. <car...@ma...> - 2001-11-28 22:05:30
|
Excellent ideas. I agree with nearly everything except the images. To summarize then: - embed translatable strings in the templates, leaving only one set of html templates in themes. - templates inside top level of theme e.g. "/themes/default/browse.template" or "browse.tmpl" - style sheets served by php script (<link rel="stylesheet" href="index.php?action=css" type="text/css" />) - move remaining files out of /admin (perhaps into "/lib") - gather up installation notes, theme instructions & docs into "/doc" - name theme configuration script "/themes/default/config.php" (in "themes/ $theme/") - "tests/unit_test_backend_cvs.php" accessible via http Here's an idea I just thought of regarding the images. - Keep the default "wikibase.png", "signature.png" and "png.png" in /images - /themes/default/config.php will set $signature and $logo pointing to /images - any additional themes which need to include differently colored logos etc. can place them in their theme directory, and its config.php would point to it: "/themes/Forge/config.php" could specify $logo="/themes/Forge/ SteelyDanSig.png" etc. Carsten |
From: Jeff D. <da...@da...> - 2001-11-29 02:06:25
|
On Wed, 28 Nov 2001 17:05:25 -0500 "Carsten Klapp" <car...@ma...> wrote: > - embed translatable strings in the templates, leaving only one set of > html templates in themes. I've got that more or less done here at home. I'll check it in within a few hours. > - style sheets served by php script (<link rel="stylesheet" > href="index.php?action=css" type="text/css" />) I'll add this to my to-do list. For now, let's just leave the style sheets in the top level directory. (Unless you write new style sheets (for new themes), in which case put them in themes/wherever/...) > - move remaining files out of /admin (perhaps into "/lib") There's actually nothing in admin that is currently functional. Everything that gets used by the main code has already been moved to lib. Just leave /admin alone for now --- we'll clean it up at some point. > - gather up installation notes, theme instructions & docs into "/doc" This can wait, too... Steve's probably the one who should decide how to move the docs around. We should probably leave at least one top-level README file to point people to the doc subdir. > - Keep the default "wikibase.png", "signature.png" and "png.png" in /images > - /themes/default/config.php will set $signature and $logo pointing to > /images > - any additional themes which need to include differently colored logos > etc. can place them in their theme directory, and its config.php would > point to it: "/themes/Forge/config.php" could specify $logo="/themes/Forge/ > SteelyDanSig.png" etc. Personally, I'd really prefer if images would stay in the images subdirectory (since then, that's the only sub-tree which needs to be HTTP accessible, which makes life simpler for lots of people). If you want to put theme-specific graphics in subdirectories of /images that makes sense. E.g. "$logo=themes/Forge/SteelyDanSig.png". I don't know how anybody else feels about this. You might want to wait another day or so to see if anyone else pipes up. |
From: Carsten K. <car...@ma...> - 2001-11-29 04:12:28
|
Sounds reasonable to keep them in /images so it's the only dir accessible by http. Also, we're already talking about moving a whole bunch of stuff as it is, no point in warping our heads around too many new changes at once (well speaking for myself anyway). :-) To everyone on the list: I'm sorry for moving files around without consulting the list first--I won't move anything else on the server for a while. Still having some trouble with my cvs client but I'm pretty sure I just need to do some more reading up on CVS. On Wednesday, November 28, 2001, at 09:06 pm, Jeff Dairiki wrote: > > Personally, I'd really prefer if images would stay in the images > subdirectory (since then, that's the only sub-tree which needs > to be HTTP accessible, which makes life simpler for lots of people). > If you want to put theme-specific graphics in subdirectories of /images > that makes sense. E.g. "$logo=themes/Forge/SteelyDanSig.png". > > I don't know how anybody else feels about this. You might want to wait > another day or so to see if anyone else pipes up. |
From: Lawrence A. <la...@20...> - 2001-11-29 11:28:44
|
At 02:06 29/11/2001, Jeff Dairiki wrote: >On Wed, 28 Nov 2001 17:05:25 -0500 >"Carsten Klapp" <car...@ma...> wrote: > > > > - move remaining files out of /admin (perhaps into "/lib") > >There's actually nothing in admin that is currently functional. >Everything that gets used by the main code has already been moved >to lib. Just leave /admin alone for now --- we'll clean it up at >some point. As long as we don't forget :-) > > - gather up installation notes, theme instructions & docs into "/doc" > >This can wait, too... Steve's probably the one who should decide how to >move the docs around. We should probably leave at least one top-level >README >file to point people to the doc subdir. > I am very keen for this to happen. I don't like the idea of having accessible docs in the root directory (even if they don't say anything confidential). It is much cleaner and easier to control access if they are in a subdir. > > - Keep the default "wikibase.png", "signature.png" and "png.png" in >/images > > - /themes/default/config.php will set $signature and $logo pointing to > > /images > > - any additional themes which need to include differently colored logos > > etc. can place them in their theme directory, and its config.php would > > point to it: "/themes/Forge/config.php" could specify >$logo="/themes/Forge/ > > SteelyDanSig.png" etc. > >Personally, I'd really prefer if images would stay in the images >subdirectory (since then, that's the only sub-tree which needs >to be HTTP accessible, which makes life simpler for lots of people). >If you want to put theme-specific graphics in subdirectories of /images >that makes sense. E.g. "$logo=themes/Forge/SteelyDanSig.png". I agree with Jeff, but no strong views. Lawrence ==========NOTICE========== Internet e-mail is not necessarily secure or reliable. Please let us know if you would like to establish a secure channel of communication. This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation. Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message. Tel: +44 (0)207 842 1200 http://www.20essexst.com pos...@20... |
From: Steve W. <sw...@pa...> - 2001-12-01 21:41:18
|
On Thu, 29 Nov 2001, Lawrence Akka wrote: > > > - gather up installation notes, theme instructions & docs into "/doc" > > > >This can wait, too... Steve's probably the one who should decide how to > >move the docs around. We should probably leave at least one top-level > >README > >file to point people to the doc subdir. > > > > I am very keen for this to happen. I don't like the idea of having > accessible docs in the root directory (even if they don't say anything > confidential). It is much cleaner and easier to control access if they are > in a subdir. I can take care of this. Cleaning up the root directory is a good thing. Images should stay in images/ and below... ~swain --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa |
From: Reini U. <ru...@x-...> - 2001-11-29 05:42:04
|
Jeff Dairiki schrieb: > o Have to pay attention to the HTTP cache-control headers when we > serve up the CSS, so that the browser doesn't have to reload it > for every page view. (We should probably be paying more attention > to the cache-control headers anyway...) i did it, but to summarize: easy to add but a nightmare with timezones. almost every site I have a wiki installed has a different and wrong timezone setting. this in collaboration with various browsers on various systems. mostly example summertime (CEST / CET) and localtime system support at all. windows is okay, but glibc2 <=2.2 doesn't work for me most of the time. i'm just too stupid so i hardcoded the abbrevation from GMT. works fine now with with IE/windows as browser. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |