phpwiki-talk

[Phpwiki-talk] /tmp warnings

[Joel U. <uck...@no...>]

I switched my test wiki over to flat file last night while I was trying to
help the guy who lost his data, and noticed that the flat file backend
doesn't issue a warning on every page about storing your data in /tmp
like the DBA backend does---or rather, used to.

A grep over the source tree reveals that the function in WikiDB_dba where the
/tmp warning occurs, genericWarnings(), is never called (unless it's being
called in some non-obvious way, and not explicitly by name). That leads me
to think that this function is cruft, since all other warnings and notices
seem to be issued with trigger_error. Am I right about that? (If so, I'll
fix the error in WikiDB_dba and add one to WikiDB_file.)

I think I understand why we didn't have that warning in the file backend---
anyone who changed the wiki to use flat files would necessarily have had the
/tmp warning in the config file appear on their screen---but it seems like an
easy way to protect from themselves those who neglect to read the instructions.

Re: [Phpwiki-talk] Please help!

[Joel U. <uck...@el...>]

> I have discovered the problem with the help of someone on IRC.  My /tmp 
> directory was deleted.
> 
> I can't even describe the rage that I have at this news.  All my long 
> hours of work were completely destroyed in one clean sweep.  I will 
> never have it back, it is gone, and for no good reason.  I think I have 
> never in my entire life heard of something as stupid as making /tmp the 
> default data store for a program.  My disappointment in the phpwiki 
> software is immeasurable.  I know now that because of todays experience 
> I will never use phpwiki ever again.
> 
> I'm just so angry, I have to go do something else now.
> 
> -d

There *is* a good reason for having /tmp as the default location for the 
wiki database: It's the only place where we can be sure that your web 
server has write permission; without that as a default, it's impossible for 
the wiki to run 'out of the box'.

And, quoting from the INSTALL file, Configuration, section 1:

"PhpWiki will create some DBA files in '/tmp'. They contain the pages
of the live site, archived pages, and some additional information.

If you don't want the DBA files to live in '/tmp' you must make sure
the web server can read/write to your chosen location.  It's probably
a bad idea to leave it in '/tmp', so change it in 'config/config.ini'.

WARNING: On many systems, files in '/tmp' are subject to periodic
         removal. We very strongly advise you to move the files to
         another directory."

What's quoted here is very near the top of the install instructions; it's 
not buried someplace obscure. We've prominently displayed a warning that 
covers exactly what happened to you, along with an explanation of how to 
avoid it.

To sum up: I'm sorry that you lost your work, but I think that your 
disappointment in PhpWiki is misdirected.

-- 
J.

Re: [Phpwiki-talk] Please help!

[Mitch A. <ma...@ma...>]

Hmmm,

critical data - no backups...

hey, I know, let's blame the programmers who donated all their time and 
effort - they must have made the mistake! Yea, that's it!

geez - grow up.. take responsibility

Mitch
please help me get free music - click this link to see how:
http://lin.kz/?e6u80


On Feb 17, 2005, at 11:09 PM, Charles Corrigan wrote:

> On Fri, February 18, 2005 12:55, David Howland said:
>> I have discovered the problem with the help of someone on IRC.  My 
>> /tmp
>> directory was deleted.
>>
>> I can't even describe the rage that I have at this news.
>
> from config/config-dist.ini:
> ; WARNING: leaving this as the default of '/tmp' will almost guarantee 
> that
> ; you'll lose your wiki data at some stage.
> DATABASE_DIRECTORY = /tmp
>
> Go figure.
>
> regards,
> Charles

Re: [Phpwiki-talk] Please help!

[Charles C. <ch...@ru...>]

On Fri, February 18, 2005 12:55, David Howland said:
> I have discovered the problem with the help of someone on IRC.  My /tmp
> directory was deleted.
>
> I can't even describe the rage that I have at this news.

from config/config-dist.ini:
; WARNING: leaving this as the default of '/tmp' will almost guarantee that
; you'll lose your wiki data at some stage.
DATABASE_DIRECTORY = /tmp

Go figure.

regards,
Charles

Re: [Phpwiki-talk] Please help!

[David H. <met...@fa...>]

I have discovered the problem with the help of someone on IRC.  My /tmp 
directory was deleted.

I can't even describe the rage that I have at this news.  All my long 
hours of work were completely destroyed in one clean sweep.  I will 
never have it back, it is gone, and for no good reason.  I think I have 
never in my entire life heard of something as stupid as making /tmp the 
default data store for a program.  My disappointment in the phpwiki 
software is immeasurable.  I know now that because of todays experience 
I will never use phpwiki ever again.

I'm just so angry, I have to go do something else now.

-d

Re: [Phpwiki-talk] Please help!

[David H. <met...@fa...>]

Joel Uckelman wrote:
> Search for some page which you know you changed. Look at the page history 
> for that page. What do you see? Do your revisions show up?

They are completely gone.  Nothing is there.  Its as if I never did 
anything.  The revisions shows nothing but the pages created during the 
first run.  I'm startic to panic.

-d

Re: [Phpwiki-talk] Please help!

[Joel U. <uck...@el...>]

> I created a phpwiki last month, for a personal project.  I have many 
> hours of work into this wiki.  After giving it a rest for a little 
> while, I just checked back.  EVERYTHING is gone!  All my work, the 
> entire wiki, has completely disappeared.  I was greeted with the Virgin 
> wiki page again.  I don't know what happened, but my login still works. 
>   Please, please, PLEASE tell me there is some way to restore my work. 
> I was storing the wiki in a flatfile.
> 
> Any help would be appreciated, please get back soon!  Thanks.
> 
> -d

Search for some page which you know you changed. Look at the page history 
for that page. What do you see? Do your revisions show up?



-- 
J.

[Phpwiki-talk] Please help!

[David H. <met...@fa...>]

I created a phpwiki last month, for a personal project.  I have many 
hours of work into this wiki.  After giving it a rest for a little 
while, I just checked back.  EVERYTHING is gone!  All my work, the 
entire wiki, has completely disappeared.  I was greeted with the Virgin 
wiki page again.  I don't know what happened, but my login still works. 
  Please, please, PLEASE tell me there is some way to restore my work. 
I was storing the wiki in a flatfile.

Any help would be appreciated, please get back soon!  Thanks.

-d

[Phpwiki-talk] Themes and Rendering

[(YOD) <yo...@pn...>]

I'm using 1.3.7 and have two Wiki sites. On one I'm using MacOSX and on 
the other the theme is Hawaiian. Everything renders find in Foxfire but 
when using IE the scrolling is very slow and I think it is because of the 
background image. Is there anyway to get around this short of changing the 
image?? Anyone have this problem also? Of course my preference is Foxfire 
but not everyone who uses the Wiki sites use Foxfire so I want the pages 
to render well in both.

Hank

Re: [Phpwiki-talk] Bugs in latest CVS Version

[Reini U. <ru...@x-...>]

[posted from my webmail]

bad news:
Three of my three harddiscs died logically today, resp. need some time to
recover.

chkdsk /f on the first disc inserted on another computer runs for 6 hrs now.
So I doubt that I will make it this weekend...

[Phpwiki-talk] Bugs in latest CVS Version

[Stefan <son...@ba...>]

Hello hopefully testing the new cvs version 1.3.11

following problems using Mysql and DATABASE_TYPE = SQL

only getting a blank page when starting the wiki
following error in php error log
[16-Feb-2005 22:25:11] PHP Fatal error:  Cannot instantiate non-existent 
class:  wikidb_backend_peardb_peardb in 
/www/htdocs/lex1/lib/WikiDB/SQL.php on line 20

following problems using Mysql and DATABASE_TYPE = ADODB

------------
Fatal Error:

lib/WikiDB/adodb/adodb-errorhandler.inc.php:76: Error: ADONewConnection 
error: [-998: could not load the database driver for '] in 
ADONewConnection(, )

lib/IniConfig.php:210: Notice: missing config setting for ADMIN_USER 
(...repeated 2 times)

lib/IniConfig.php:556: Notice: The admin password cannot be empty. 
Please update your config/config.ini

lib/WikiDB/ADODB.php:17: Notice: Undefined index: dsn

lib/WikiDB/ADODB.php:19: Notice: Undefined index: dsn

lib/WikiDB/ADODB.php:23: Notice: Undefined variable: backend

lib/WikiDB/adodb/adodb-errorhandler.inc.php:76: Error: ADONewConnection 
error: [-998: could not load the database driver for '] in 
ADONewConnection(, )
-------

ADMIN_USER and Password is set
the database is installed with the newest schema

Now i use 1.3.10 with DATABASE_TYPE = SQL this works fine but i thought 
1.3.11 will be out soon :-(
whats wrong?

Regards Stefan

[Phpwiki-talk] =?GB2312?B?kvGIxILFgreCqoFCgUKBQg==?=

[sdafks <as...@as...>]

™™™™™™„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
™™™™™@@@@@ƒlƒbƒg‰SŽÒ‚Å‚àˆÀS
™™™™
™™™@@@@@@@Š®‘S–³—¿‚Ì‚g‚ȏo‰ï‚¢ƒKƒCƒh
™™
™@@@@@@@@@http://www.gameboys.cc/
„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª™™™™™


’–Ú‚Pjƒƒ“ƒNƒŠƒbƒN¼‹\‚â•s³“‘£‚͈êØ‚È‚µI
@@@@¼‹\¿‹–o–ňψõ‰ïNo.000009
@@@@http://www.gameboys.cc/

’–Ú‚Qj‘åŽèƒp[ƒ\ƒiƒ‹Œn‚ł͏o‰ï‚¦‚È‚¢——RB
@@@@ŽÀÑ‚Æ•ªÍ‚©‚ç‚»‚̃Jƒ‰ƒNƒŠ‚ðB
@@@@http://www.gameboys.cc/


™*`*™*`*™*`*™*`*™*`*™*`*™*`*™*`*™*`*™*`*™


ÅV‘‚«ž‚Ý’²¸•ñ

™„ª„ª„ª„ª„ª„±„ª„ª„ª„±„ª„ª„ª„ª„±„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«‚Ý‚¦‚Ý‚¦š„«‚P‚WÎ„«ŠÖ“Œ’n•û„«ƒAƒ|•åW’†
„°„ª„ª„ª„ª„ª„³„ª„ª„ª„³„ª„ª„ª„ª„³„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«http://www.gameboys.cc/
„¯„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª

™„ª„ª„±„ª„ª„ª„±„ª„ª„ª„ª„±„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«ŽÑ‰Ô„«‚Q‚SÎ„«‹ß‹E’n•û„«ƒAƒ|•åW’†
„°„ª„ª„³„ª„ª„ª„³„ª„ª„ª„ª„³„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«http://www.gameboys.cc/
„¯„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª

™„ª„ª„ª„ª„ª„ª„±„ª„ª„ª„±„ª„ª„ª„ª„±„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«‚Ì‚è‚Á‚¿‚¡B„«‚Q‚RÎ„«“Œ–k’n•û„«ƒAƒ|•åW’†
„°„ª„ª„ª„ª„ª„ª„³„ª„ª„ª„³„ª„ª„ª„ª„³„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«http://www.gameboys.cc/
„¯„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª

™„ª„ª„±„ª„ª„ª„±„ª„ª„ª„ª„±„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«•Ð—ƒ„«‚Q‚QÎ„«’†•”’n•û„«ƒAƒ|•åW’†
„°„ª„ª„³„ª„ª„ª„³„ª„ª„ª„ª„³„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«http://www.gameboys.cc/
„¯„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª

™„ª„ª„±„ª„ª„ª„±„ª„ª„ª„±„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«’qŽq„«‚Q‚RÎ„«–kŠC“¹„«ƒAƒ|•åW’†
„°„ª„ª„³„ª„ª„ª„³„ª„ª„ª„³„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«http://www.gameboys.cc/
„¯„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª

„¬„ª„ª„±„ª„ª„ª„±„ª„ª„ª„ª„±„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«Žu”T„«‚Q‚TÎ„«’†‘’n•û„«ƒAƒ|•åW’†
„°„ª„ª„³„ª„ª„ª„³„ª„ª„ª„ª„³„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
„«http://www.gameboys.cc/
„¯„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª


‚»‚Ì‘¼A‚TC‚W‚Q‚QŒ‚̐V’…‚ª‚ ‚è‚Ü‚·B
‘±‚«Ëhttp://www.gameboys.cc/


™*`*™*`*™*`*™*`*™*`*™*`*™*`*™*`*™*`*™*`*™
Šm‚©‚ȏî•ñA³‚µ‚¢ƒlƒbƒgƒ‰ƒCƒt‚ð

ƒCƒ“ƒ^[ƒlƒbƒgƒKƒCƒh(“ú–{”Å)
http://www.gameboys.cc/

Re: [Phpwiki-talk] Status update

[Reini U. <ru...@x-...>]

Dan Frankowski schrieb:
> Reini Urban wrote:
>> I'm quite fed up with my slow THEME=blog advances.
>> Missing is plugin BlogJournal and the two blog links (permlinks and 
>> comments). So I will probably not include it into the upcoming 1.3.11 
>> release, unless someone else jumps in.
>> Attached is the current BlogJournal.
>>
>> What is missing now is to test against:
>> * the lately reported strict auth problems,
>> * basic wikilens features (I had no time at all for adding the
>>   latest wikilens features, sorry Dan)
> 
> No need to apologize! That's something we should be helping with. We are 
> just waiting until 1.3.11 comes out, then a few weeks to see if it is 
> stable, then integrate it into our stuff (probably more weeks), then try 
> to give changes back.
> 
> By the way, I agree with Oliver Betz, a stable, solid, easy-to-use, 
> timely release is much more important than new features.

Ok.

Can someone comment or fix the new configurator?
Testing is easy by using no config/config.ini (rename)
There might be some more slash and quoting problems.

I have some idea about some improvements for 1.3.12,
but this should be the 1.3.11rc.

The current version produces a lot of commented options, doesn't check 
for defaults (which should be the real cause for a commented option to 
be printed), but at least it's almost complete.

1.3.11 TODO: (or 1.3.12?)
  * fix AUTH_ORDER quotes and file forward slashes
  * commented / optional: non-default values should not be commented!
  *                       default values if optional can be omitted.
  * read config-default.ini to detect optional
  * read existing config-dist.ini into sections, comments, and
  *   optional/required settings

Of course the single page layout is horrible, and should be changed to 
multipage, but we have the same mess in upgrade.
And we should the advantages of dynamic checks for bad options.
   (dir exists, file exists, file writable, ...)
-- 
Reini Urban

Re: [Phpwiki-talk] Status update

[Dan F. <dfr...@cs...>]

Reini Urban wrote:

> I'm quite fed up with my slow THEME=blog advances.
> Missing is plugin BlogJournal and the two blog links (permlinks and 
> comments). So I will probably not include it into the upcoming 1.3.11 
> release, unless someone else jumps in.
> Attached is the current BlogJournal.
>
> What is missing now is to test against:
> * the lately reported strict auth problems,
> * basic wikilens features (I had no time at all for adding the
>   latest wikilens features, sorry Dan)


No need to apologize! That's something we should be helping with. We are 
just waiting until 1.3.11 comes out, then a few weeks to see if it is 
stable, then integrate it into our stuff (probably more weeks), then try 
to give changes back.

By the way, I agree with Oliver Betz, a stable, solid, easy-to-use, 
timely release is much more important than new features.

Dan

Re: [Phpwiki-talk] Status update

[Oliver B. <ob...@de...>]

Reini Urban <ru...@x-...> wrote:

> I want to bring out 1.3.11 and 1.2.8 this week.

great, thanks!

And IMHO a stable release is much more important than new features!

Oliver

Re: [Phpwiki-talk] add pointer to security documentation

[Reini U. <ru...@x-...>]

Charles Corrigan schrieb:
>  INSTALL.MacOSX         for using PhpWiki in MacOSX
>  README.phpwiki-auth    for using authentication
> +README.security        for notes on implementing a more secure PhpWiki

Thanks!

Note that I added similar sufficient security information to the new 
configurator also. I'm just not sure if it works good enough with the 
new autodetection, if no installation (config/config.ini) is found.

1. I have to test ENABLE_FILE_OUTPUT and
2. when the starter script is not in PHPWIKI_DIR, DATA_PATH must be 
defined in the starter script.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] add pointer to security documentation

[Charles C. <ch...@ru...>]

Index: README
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/README,v
retrieving revision 1.18
diff -u -r1.18 README
--- README	17 Dec 2004 09:23:41 -0000	1.18
+++ README	15 Feb 2005 14:26:24 -0000
@@ -15,6 +15,7 @@
 INSTALL.flatfile       for using PhpWiki with flat files, no database
 INSTALL.MacOSX         for using PhpWiki in MacOSX
 README.phpwiki-auth    for using authentication
+README.security        for notes on implementing a more secure PhpWiki
 README.phpwiki-cache   for using cached plugins content (VisualWiki, ...)
 README.coding          for notes on modifying PhpWiki
 README.foaf            for notes on the Friend Of A Friend network

[Phpwiki-talk] ziphtml produces corrupt zip files...

[John C. <joh...@ua...>]

Reini,
  I was just trying the ziphtml action and it seems to produce invalid zip
files.  I tried in both macosx and crao themes.

  I refreshed from CVS this morning.

Thanks,

John

-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

RE: [Phpwiki-talk] Status update

[Charles C. <ch...@ru...>]

On 14 February 2005 22:48, John Cole wrote:
> I'm going to roll this version live and see how well it stands up.

Note that there is a problem with the Sourceforge anonymous CVS server for projects that start with p (and other nearby letters).  I
cannot get an update from CVS until the Source forge staff fix the problem.

Regards,
Charles

RE: [Phpwiki-talk] Status update

[John C. <joh...@ua...>]

Reini,
  I just gave the the cvs HEAD as spin on my test server, and everything
seems to still work :-)

  One thing that seems to still be broken is the page rename on the admin
screen.

  I'm going to roll this version live and see how well it stands up.

John

-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Reini Urban
Sent: Monday, February 14, 2005 6:09 AM
To: php...@li...
Subject: [Phpwiki-talk] Status update

I'm quite fed up with my slow THEME=blog advances.
Missing is plugin BlogJournal and the two blog links (permlinks and 
comments). So I will probably not include it into the upcoming 1.3.11 
release, unless someone else jumps in.
Attached is the current BlogJournal.

What is missing now is to test against:
* the lately reported strict auth problems,
* basic wikilens features (I had no time at all for adding the
   latest wikilens features, sorry Dan)
* finally fix the still broken locale or revert back to 1.3.10
   (without DEFAULT_LANGUAGE='' autodetection support)
* finish Discussion/Article (add Article) navbar link
* check several minor bugs
* fix TextSearchQuery::optimize() with "word -word -word"
   (without optimize it works fine)

I start a new 40hr job on wednesday, so I will have less time for 
phpwiki. Only at the weekend and after 5pm.
But finally my router works again, so I can cvs diff/commit directly.
I want to bring out 1.3.11 and 1.2.8 this week.
-- 
Reini Urban
http://phpwiki.org/


-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

Re: [Phpwiki-talk] TitleSearch.php is broken in CVS Version

[Reini U. <ru...@x-...>]

Stefan schrieb:
> Problem in TitleSearch.php using complexer serach patterns. The page 
> will never finished
> 
> pattern like "Eifel/ -Mineralien -Bilder"

Thanks. Good catch!

"Blog/ -2004" correctly finds all Blog subpages not in 2004
But "Blog/ -2004 -2005" found an error in the optimizer.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Status update

[Reini U. <ru...@x-...>]

I'm quite fed up with my slow THEME=blog advances.
Missing is plugin BlogJournal and the two blog links (permlinks and 
comments). So I will probably not include it into the upcoming 1.3.11 
release, unless someone else jumps in.
Attached is the current BlogJournal.

What is missing now is to test against:
* the lately reported strict auth problems,
* basic wikilens features (I had no time at all for adding the
   latest wikilens features, sorry Dan)
* finally fix the still broken locale or revert back to 1.3.10
   (without DEFAULT_LANGUAGE='' autodetection support)
* finish Discussion/Article (add Article) navbar link
* check several minor bugs
* fix TextSearchQuery::optimize() with "word -word -word"
   (without optimize it works fine)

I start a new 40hr job on wednesday, so I will have less time for 
phpwiki. Only at the weekend and after 5pm.
But finally my router works again, so I can cvs diff/commit directly.
I want to bring out 1.3.11 and 1.2.8 this week.
-- 
Reini Urban
http://phpwiki.org/

Re: [Phpwiki-talk] Re: Another use for Google's 'rel='nofollow''?

[Reini U. <ru...@x-...>]

Charles Corrigan schrieb:
> On Mon, January 31, 2005 17:43, Charles Corrigan said:
>>On Thu, January 27, 2005 17:31, Charles Corrigan said:
>>>I just looked at the access log for my site and noticed
>>>that google was indexing it. And it was trying every
>>>possible link from every page!
>>>
>>>Would it make sense to add a "rel='nofollow'" to links
>>>such as "edit text" where it makes no sense for a robot
>>>to follow?
>>
>>When I wrote that, it was already 7 days after Reini had started putting
>>the nofollow attribute onto some of the links! My only excuse (hah!) is
>>that CVS and then the lists had problems last week.
> 
> Google just re-indexed my site and, again, followed all links, including
> action=edit etc.  I looked into Google's spec and realised that the
> rel="nofollow" only means that the link does not contribute to pagerank.
> It does not mean that the link will not be followed.

Thanks for clarification!

> It looks like the only way to handle this is via the robots.txt.  Google
> support an extension to the specification that allows wildcards to be
> specified in the Disallow field (see
> http://www.google.com/intl/en/webmasters/3.html ).

We also use the robots meta tag, which says that those initial action 
links are followed, but subsequent links and indexing in the action page 
are forbidden. This should be easier to setup (cost: none) than using a 
hardcoded robots.txt file, but allows one more link.

normal + RecentChanges:
   <meta name="robots" content="index,follow" />
most action pages:
   <meta name="robots" content="noindex,nofollow" />

PS: We might want to change action=BackLinks to the first rule, as 
another exeption along with RecentChanges.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: Another use for Google's 'rel='nofollow''?

[Charles C. <ch...@ru...>]

On Mon, February 14, 2005 17:13, someone asked:
> Not
> Disallow: *action=*

In my opinion, no:
1 - no trailing * is required ;-)
2 - some actions, such as action=LikePages, action=RelatedChanges and, in
particular, action=BackLinks make sense

Please note that the specification for robots.txt state that robots will
retrieve it from the root directory, i.e. /robots.txt - so what I sent in
is a subset of the full robots.txt file for my site.

regards,
Charles

[Phpwiki-talk] Re: Another use for Google's 'rel='nofollow''?

[Charles C. <ch...@ru...>]

On Mon, January 31, 2005 17:43, Charles Corrigan said:
> On Thu, January 27, 2005 17:31, Charles Corrigan said:
>> I just looked at the access log for my site and noticed
>> that google was indexing it. And it was trying every
>> possible link from every page!
>>
>> Would it make sense to add a "rel='nofollow'" to links
>> such as "edit text" where it makes no sense for a robot
>> to follow?
>
> When I wrote that, it was already 7 days after Reini had started putting
> the nofollow attribute onto some of the links! My only excuse (hah!) is
> that CVS and then the lists had problems last week.

Google just re-indexed my site and, again, followed all links, including
action=edit etc.  I looked into Google's spec and realised that the
rel="nofollow" only means that the link does not contribute to pagerank.
It does not mean that the link will not be followed.

It looks like the only way to handle this is via the robots.txt.  Google
support an extension to the specification that allows wildcards to be
specified in the Disallow field (see
http://www.google.com/intl/en/webmasters/3.html ).

The new contents of my robots.txt file follow,

regards,
Charles

# robots.txt - Charles Corrigan - 14/2/2005
# This robots.txt file uses a non-standard format that is followed by
# Google. This format allows the use of wildcards in the page names
# and is used here to advise robots not to follow links in PhpWiki that
# are not relevant.
User-agent: *
Disallow: /*action=chmod
Disallow: /*action=chown
Disallow: /*action=create
Disallow: /*action=DebugInfo
Disallow: /*action=diff
Disallow: /*action=edit
Disallow: /*action=EditMetaData
Disallow: /*action=EditMetaInfo
Disallow: /*action=loadfile
Disallow: /*action=lock
Disallow: /*action=PageDump
Disallow: /*action=PageHistory
Disallow: /*action=PageInfo
Disallow: /*action=PhpWikiAdministration%2FChmod
Disallow: /*action=PhpWikiAdministration%2FChown
Disallow: /*action=PhpWikiAdministration%2FRemove
Disallow: /*action=PhpWikiAdministration%2FRename
Disallow: /*action=PhpWikiAdministration%2FReplace
Disallow: /*action=PhpWikiAdministration%2FSetAcl
Disallow: /*action=remove
Disallow: /*action=rename
Disallow: /*action=replace
Disallow: /*action=setacl
Disallow: /*action=TranslateText
Disallow: /*action=unlock
Disallow: /*action=upgrade
Disallow: /*action=viewsource
Disallow: /*action=zip
Disallow: /*action=ziphtml