phpwiki-talk

[Phpwiki-talk] Photoshop, Windows, Office. CHEAP.

[Adler Jennifer<fl...@ya...>]

See attachment message.html

Re: [Phpwiki-talk] special characters/umlaute/accents

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

Scheider, Hendrik schrieb:
> I am having trouble with a special character in my page sources: the Euro
> currency sign, though directly input as character in the edit form (my
> keyboard has it as key), is converted to € in the page source (with
> the ampersand then escaped as entity for output).

Only the server-defined charset is possible. (mostly iso-8859-1)
otherwise the connection from the client to the server and the 
connection from the server to the database will be undefined.

> I found some ancient discussion on the accent/umlaut issue on the list
> here http://sourceforge.net/mailarchive/message.php?msg_id=3872323
> and here http://sourceforge.net/mailarchive/message.php?msg_id=494295
> 
> but don't know the actual state. At least German umlaute and Roman language
> accents work fine even as wiki links (url_encoded in the URL, but unescaped
> for output). Furthermore I am totally inexperienced in the field of charset
> encodings.

The actual state is a bit better now (see the problems jeff talks about 
in the first link)
Special &#<num>; encodings are now (since a few days in CVS only) 
allowed, which are displayed asis. This is problematic for searches e.g.

Markup_isonumchars in InlineParser.
   regex: "\&\#\d{2,5};"
e.g. &#133;

> I am using php 4.3.10 on apache 1.3.33 and mysql 4.1
> with
> extension=php_mbstring.dll
> turned on in PHP.

Aha. That makes a difference. I wouldn't turn that on unless you use 
japanese charsets.
mbstring does charset conversion also, which is independent of phpwiki.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] special characters/umlaute/accents

[Scheider, H. <Hen...@wi...>]

Dear users and team,

I am having trouble with a special character in my page sources: the Euro
currency sign, though directly input as character in the edit form (my
keyboard has it as key), is converted to € in the page source (with
the ampersand then escaped as entity for output).

I found some ancient discussion on the accent/umlaut issue on the list

here http://sourceforge.net/mailarchive/message.php?msg_id=3872323

and here http://sourceforge.net/mailarchive/message.php?msg_id=494295

but don't know the actual state. At least German umlaute and Roman language
accents work fine even as wiki links (url_encoded in the URL, but unescaped
for output). Furthermore I am totally inexperienced in the field of charset
encodings.


I am using php 4.3.10 on apache 1.3.33 and mysql 4.1

with
extension=php_mbstring.dll

turned on in PHP.


Thanks for your help,

Hendrik Scheider

_______________________________________
 
Wincor Nixdorf International GmbH
Retail Store Solutions
Java Solution Group

Wernerwerkdamm 16
13629 Berlin
Tel: +49 (0) 30 5017 1219
Fax: +49 (0) 30 5017 1305

[Phpwiki-talk] PDO support added.

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

After some discussion with Wez Furlong on pecl I added PDO support to 
WikiDB. Php5 support seems to be very stable now.

Currently tested versions: win32/mysql-4.1.8/pdo-0.2/php-5.0.3 only.
sqlite and pgsql might need some minor fixes in the initializer and 
upgrade methods.

PDO is much simplier and faster than ADODB or pear DB, but only works on 
PHP5.
pdo-0.2.1 and newer is not really needed.
execute(args), quote and cached prepared statements are not needed for 
phpwiki.

Porting for phpwiki needed 2 hours, mostly converting simple adodb or 
pear db execute statements to the prepare/bindParam/execute syntax and 
changing the fetch calls. Exactly as in perl's DBI.
Once I caught the transaction ability via try/catch it was easy to 
workaround, a lot easier than in the php4 adodb/pear db backends.

I also have the pecl-based cvsclient backend sitting around here for 
some months, but don't wan't to spend any time on it, unless someone 
really needs it.

In the future I will work with oracle at my new company, so expect some 
improvements there.
-- 
Reini Urban
http://phpwiki.org/

[Phpwiki-talk] private wiki and recent changes rss

[Arnaud F. <ar...@cr...>]

Hi,

I have a problem on a private wiki running CVS phpwiki.

It uses authentification with "File" ... and I can't figure out how to
retrieve the RecentChanges rss feed.

I tried to add HttpAuth to the File method (USER_AUTH_ORDER =3D
"File:HttpAuth" with USER_AUTH_POLICY =3D stacked) and gave the user and
password in the url ... no way.

Any idea ?
--=20
Arnaud Fontaine
CRAO
jabber : sh...@ra...

RE: [Phpwiki-talk] Two new queries on search engine activity for AnalyseAccessLog plugin

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

On 07 February 2005 18:40, Reini Urban [mailto:ru...@x-...] wrote

>>         ."WHERE (remote_host LIKE '%googlebot.com' "
>>         ."OR remote_host LIKE '%alexa.com' "
>>         ."OR remote_host LIKE '%inktomisearch.com' "
>>         ."OR remote_host LIKE '%msnbot.msn.com') "
>
>For search bots you can constrcut the hosts string from 
>lib/ExternalReferrer.php

I took a look - this handles the URL for main site of the search engine but not necessarily the crawler engine URL.  For example:
google.com vs googlebot.com. Also, some of these sites use hand built indices rather than crawlers to automatically generate the raw
material.

I could add a new column to the array in ExternalReferrer.php for the crawler URLs but I only have the 4 crawlers above so far...

Regards,
Charles

[Phpwiki-talk] Popular software at low low prices.

[Gersh Norah<is...@ya...>]

See attachment message.html

RE: [Phpwiki-talk] Two new queries on search engine activity for AnalyseAccessLog plugin

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

OK, attached are two files that I hope are going in the right direction.  Please review but do not commit to CVS yet as they are
untested and an API change is inadequately documented.

AccessLogSQL.php replaces AnalyseAccessLog.php and AccessLogSQLMySQL.inc replaces AnalyseAccessLog.php

I will revise the wiki page that I provided earlier once the code changes are complete

Regards,
Charles

Re: [Phpwiki-talk] Some thoughts about phpwiki

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

Âëàäèìèðîâ Ìèõàèë Àëåêñååâè÷ schrieb:
>>>2. 'strict' authorization scheme is broken (it tries next
>>>authentication method if previous method says, that user exists, but
>>>password is wrong).  I have fixed this bug by deleting several lines
>>>in WikiUserNew.php (first 'if' statement in function _tryNextPass of
>>>class PassUser)

It's not that simple but I found a good fix.

> RU> Thanks!
> I remember another problem.  Plugin UserPreferences does not encrypt
> passwords, even if ENCRYPTED_PASSWD is true.  I have fixed it in the
> following way:
> 
> if (empty($rp['passwd'])) unset($rp['passwd']);
> else $rp['passwd'] = $this->_encryptPassword ($rp['passwd']);
> 
> where _encryptPassword () encrypts password if ENCRYPTED_PASSWD is
> true (I used code from script passencrypt.php to implement it).

That's unfortunately wrong, because the user class stores and changes 
the passwords. You cannot do that in the plugin.

But I detected the real problem for PersonalPage users
in WikiUserNew only.
This _PassUser::changePass method forgot to crypt and more things.
(not foolproof yet)

     function changePass($submitted_password) {
         $stored_password = $this->_prefs->get('passwd');
         // check if authenticated
         if (!$this->isAuthenticated()) return false;
         if (ENCRYPTED_PASSWD) {
             $submitted_password = crypt($submitted_password);
         }
         // check other restrictions, with side-effects only.
         $result = $this->_checkPass($submitted_password, $stored_password);
         if ($stored_password != $submitted_password) {
             $this->_prefs->set('passwd', $submitted_password);
             //update the storage (session, homepage, ...)
             $this->SetPreferences($this->_prefs);
             return true;
         }
         //Todo: return an error msg to the caller what failed?
         // same password or no privilege
         return ENCRYPTED_PASSWD ? true : false;
     }


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

RE: [Phpwiki-talk] Two new queries on search engine activity for AnalyseAccessLog plugin

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

>> The main reason that I wanted to put the queries in a separate file is
>> that different database engines have different dialects of SQL and I know
>> that some queries that I have written will only work with MySQL.
>
> I see. Why not call the plugin AnalyseAccessLogSql then?
> The inc should be AnalyseAccessLogMySql.inc then.
>
> The AccessLog class has methods to support (read/write) both logfiles 
> and sql logs. This plugin only deals with the fast SQL case.

OK, this would make sense - maybe with a shorter name?

I looked at Request_AccessLog & Request_AccesslogEntry in Request.php and chose not to follow that API. For the actual transactional
part of the system, I agree totally that the backend should be as transparent as possible.  But for (added-value) reporting why
limit to the least common denominator? Unless someone wants to step up to the plate and deliver a query engine against the access
log file...

>>>Also with the name change from mode to queryName.
>>>I think we want to keep "mode" for consistency.
>> 
>> I thought long and hard about that before making the change as it really
>> is a change in API. Again, to help people that are not familiar with
>> programming PHP, I wanted
>> a) the API name to match the parameter name and
>> b) the API name to make sense
>
> queryName is too low level. Too SQL specific.

The queryName is designed to be just that, a name. mode has the implication of being built-in, whereas queryName does give the sense
of it just being an arbitrary name. And if the plugin is renamed to AnalyseAccessLogSql it should be even less of an issue

Regards,
Charles

Re: [Phpwiki-talk] column type BLOB not supported for HEAP/MEMORY type tables of MyS QL

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

Scheider, Hendrik schrieb:
> I noticed that the session table contains a column type not supported by
> MySQL when choosing the table type HEAP or MEMORY as suggested in the
> mysql.sql schema.
> 
> What shall I set the column type to instead?

http://dev.mysql.com/doc/mysql/en/memory-storage-engine.html

we allow only max 4000 chars, so varchar(4000) should be enough.
(session limitation, see also max_allowed_packet)
and mysql doesn't support that large heap tables to my knowledge yet. 
max char(255).
I never tested heap tables for sessions.

max heap table size =  16777216

DROP TABLE `session` IF EXIST;
CREATE TABLE `session` (
   `sess_id` char(32) character set latin1 NOT NULL default '',
   `sess_data` char(4000) collate latin1_bin,
   `sess_date` int(10) unsigned NOT NULL default '0',
   `sess_ip` char(15) character set latin1 NOT NULL default '',
   PRIMARY KEY  (`sess_id`),
   KEY `sess_date` (`sess_date`)
) ENGINE=MEMORY DEFAULT CHARSET=latin1 COLLATE=latin1_bin;

=> The used table type doesn't support BLOB/TEXT columns

So the next best version would be a TEMPORARY table, which are kept in 
memory until tmp_table_size is exceeded and then flushed to disc.
But for TEMPORARY table you'd need persistent connections, which will 
not work fine on overloaded servers.
And a db hook in the connection init to create it.

DROP TABLE `session` IF EXISTS;
CREATE TEMPORARY TABLE `session` (
   `sess_id` char(32) character set latin1 NOT NULL default '',
   `sess_data` BLOB collate latin1_bin,
   `sess_date` int(10) unsigned NOT NULL default '0',
   `sess_ip` char(15) character set latin1 NOT NULL default '',
   PRIMARY KEY  (`sess_id`),
   KEY `sess_date` (`sess_date`)
) DEFAULT CHARSET=latin1 COLLATE=latin1_bin;

So MyIsam/InnoDB look like the best mysql solution.
Or use one of the specialized php session modules.
-- 
Reini Urban
http://phpwiki.org/

Re: [Phpwiki-talk] Some thoughts about phpwiki

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

Âëàäèìèðîâ Ìèõàèë Àëåêñååâè÷ schrieb:
>>>1. [:alpha:], [:alnum:] and other character classes works well on my
>>>PHP installation, while phpwiki still tries to use it's buggy
>>>work-around for them.  I want to be able to switch off that
>>>work-around.
> 
> RU> We currently check in pcre_fix_posix_classes() for broken [:upper:] and
> RU> use workarounds for [:alnum:], [:alpha:], [:upper:] and [:lower:] if the
> RU> utf8 or Ä check fails.
> RU> You say that your [:upper:] check fails, but [:alpha:], [:alnum:] do
> RU> work ok? I cannot believe this.
> No, I say, that [:alpha:], [:alnum:] and other character classes works
> well, including [:upper:].  So I want to be able to disable work-around.

But the live-check must work.
utf8:
   preg_match('/[[:upper:]]/', '\xc4\x80') => true
else
   preg_match('/[[:upper:]]/', 'Ä')) => true

If this fails then something else is wrong.
If this is true, no workarounds are used.

> I remember another problem.  Plugin UserPreferences does not encrypt
> passwords, even if ENCRYPTED_PASSWD is true.  I have fixed it in the
> following way:
> 
> if (empty($rp['passwd'])) unset($rp['passwd']);
> else $rp['passwd'] = $this->_encryptPassword ($rp['passwd']);
> 
> where _encryptPassword () encrypts password if ENCRYPTED_PASSWD is
> true (I used code from script passencrypt.php to implement it).

Oops. Thanks.

> RU> What is quite difficult and for which I have no time yet, is adding
> RU> support for Markup_isonumchars in lib/InlineParser.php
> TODO: "..." =>> "…"  browser specific display (not cached?)
> TODO: "--" =>> "&emdash;" browser specific display (not cached?)
> 
> Maybe I misunderstand phpwiki architecture, but I have easily
> implemented features like this in InlineParser.php in the following
> way:
> 
> class Markup_copy extends SimpleMarkup
> {
>     var $_match_regexp = '\(C\)';
> 
>     function markup ($match) {
>         return HTML::raw ('©');
>     }
> }
> 
> RU> You want this, I believe. Currently any & is converted to & so we
> RU> should escape it somehow (functional style) or use an OO approach as in
> RU> HTML::Raw.
> I prefer something like HTML::Entity ('copy').  I hope it will be easy
> to implement.

Great. That looks fine. Though only isonumchars works so far.

class Markup_html_entities  extends SimpleMarkup {
     var $_match_regexp = '(: \.\.\.|\-\-|\-\-\-|\(C\) )';

     function markup ($match) {
         static $entities = array('...'  => '…',
                                  '--'   => '–',
                                  '---'  => '—',
                                  '(C)'  => '©',
                                  );
         return HTML::Raw($entities[$match]);
     }
}
class Markup_isonumchars  extends SimpleMarkup {
     var $_match_regexp = '\&\#\d{2,5};';

     function markup ($match) {
         return HTML::Raw($match);
     }
}
class Markup_isohexchars extends SimpleMarkup {
     // hexnums, like &#x00A4; <=> &curren;
     var $_match_regexp = '\&\#x[0-9a-fA-F]{2,4};';

     function markup ($match) {
         return HTML::Raw($match);
     }
}

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] column type BLOB not supported for HEAP/MEMORY type tables of MyS QL

[Scheider, H. <Hen...@wi...>]

Hi all,

I noticed that the session table contains a column type not supported by
MySQL when choosing the table type HEAP or MEMORY as suggested in the
mysql.sql schema.

What shall I set the column type to instead?


Kind regards,

Hendrik Scheider

_______________________________________
 
Wincor Nixdorf International GmbH
Retail Store Solutions
Java Solution Group

Wernerwerkdamm 16
13629 Berlin
Tel: +49 (0) 30 5017 1219
Fax: +49 (0) 30 5017 1305

Re: [Phpwiki-talk] Some thoughts about phpwiki

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

Mikhail Vladimirov schrieb:
> I have installed phpwiki-1.3.10 on my site, and I want to tell you,
> what I think about it.
> 
> I have tried to make Russian locale for it, to make my own theme, to
> add some new special sequences (link --- for mdash, -- for ndash, (C)
> for copyright sign e.t.c.).
> 
> I found the following difficulties:
> 1. [:alpha:], [:alnum:] and other character classes works well on my
> PHP installation, while phpwiki still tries to use it's buggy
> work-around for them.  I want to be able to switch off that
> work-around.

We currently check in pcre_fix_posix_classes() for broken [:upper:] and 
use workarounds for [:alnum:], [:alpha:], [:upper:] and [:lower:] if the 
utf8 or Ä check fails.
You say that your [:upper:] check fails, but [:alpha:], [:alnum:] do 
work ok? I cannot believe this.
Maybe you can find out why your utf8 or Ä check fails.
   preg_match('/[[:upper:]]/', 'Ä')) => true
   preg_match('/[[:upper:]]/', '\xc4\x80') => true

> 2. 'strict' authorization scheme is broken (it tries next
> authentication method if previous method says, that user exists, but
> password is wrong).  I have fixed this bug by deleting several lines
> in WikiUserNew.php (first 'if' statement in function _tryNextPass of
> class PassUser)

Thanks!

> 3. WIKI_NAME_REGEXP is used for both automatic link creation and for
> checks for valid user names.  I prefer to apply to user names weaker
> conditions, then to automatic links.  I want to be able to specify two
> different regular expressions for this two cases.

Sure. Username checks must be class methods, because the strictness is 
backend specific. auth, pref and db backend specific.
bogousers are WIKI_NAME_REGEXP specific.
pageprefs users must use pagename validity checks, based on the db 
backend. (valid filenames) We shoudl work around this filename 
limitation by using urlencode in the file backend storage mechanism. But 
not for 1.3.11 yet.
SQL pref and auth users must use SQL-specific validity checks.
LDAP auth usernames are even stricter, because it easier to fool ldap 
than properly quoted sql.

> I am an expierenced PHP programmer and I think, I can help with
> development of phpwiki.  At least I can submit Russian locale for it.
> My user name at sourceforge is mvladimirov.

Great! I always loved to work with russian programmers back in old 
Autolisp days.

What is quite difficult and for which I have no time yet, is adding 
support for Markup_isonumchars in lib/InlineParser.php
TODO: "..." => "…"  browser specific display (not cached?)
TODO: "--" => "&emdash;" browser specific display (not cached?)

You want this, I believe. Currently any & is converted to & so we 
should escape it somehow (functional style) or use an OO approach as in 
HTML::Raw.
-- 
Reini Urban
http://phpwiki.org/

Re: [Phpwiki-talk] Two new queries on search engine activity for AnalyseAccessLog plugin

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

Charles Corrigan schrieb:
> On Mon, February 7, 2005 18:39, Reini Urban said:
>>Charles Corrigan schrieb:
>>
>>>Here are two new queries that I wrote to analyse search engine activity
>>>from the SQL access log. These can be inserted into the
>>>AnalyseAccessLog.inc file that I uploaded last week - the insertion
>>>point should be just before the final "}".
>>
>>I see now why you wanted to exclude the queries, but I still don't feel
>>comfortable with the seperate .inc file.
> 
> The main reason that I wanted to put the queries in a separate file is
> that different database engines have different dialects of SQL and I know
> that some queries that I have written will only work with MySQL.

I see. Why not call the plugin AnalyseAccessLogSql then?
The inc should be AnalyseAccessLogMySql.inc then.

The AccessLog class has methods to support (read/write) both logfiles 
and sql logs. This plugin only deals with the fast SQL case.

> The secondary reason for a separate file was to document the query file's
> API simply and completely enough to allow non-PhpWiki or even non-PHP
> programmers to alter the existing queries to make them work with their
> database engine or to add new queries.
> 
> Can you suggest an alternative mechanism to achieve what I am getting at?

I will think about it.

>>That would be the first and only case, and there are several file-based
>>methods to list all our plugins (checking for .php, well).
>>it violates our current (unwritten) plugin policies.
>>
>>Also with the name change from mode to queryName.
>>I think we want to keep "mode" for consistency.
> 
> I thought long and hard about that before making the change as it really
> is a change in API. Again, to help people that are not familiar with
> programming PHP, I wanted
> a) the API name to match the parameter name and
> b) the API name to make sense

queryName is too low level. Too SQL specific.
All these modes can also be supported by logfile analysis. (the file 
based backend)
The plugin API has to deal with users and should be consistent.

>>>The queries contain a list of DNS
>>>names for search engine crawlers/spiders/whatever - but this is based
>>>only
>>>on what I saw in my sites' accesslog. Any additions are welcome.

>>>    $now = time();
>>>    $query = "SELECT "
>>>        ."IF($now-time_stamp<60, '0 - last minute', IF($now
>>>-time_stamp<3600, '1 - 1 minute to 1 hour',
>>>IF($now-time_stamp<86400, '2 - 1 hour to 1 day',
>>>IF($now-time_stamp<604800, '3 - 1 day to 1 week',
>>>IF($now-time_stamp<2629800, '4 - 1 week to 1 month',
>>>IF($now-time_stamp<31557600, '5 - 1 month to 1 year', '6 - more
>>
>>All these are untranslated strings.
> 
> Good point, I will see what I can do - to get it "right" may require some
> support in the main php file.

Our current xgettext (automatic message string extractor) doesn't look 
at .inc files. So I would use php vars and define them in the plugin php 
file.
_("1 minute to 1 hour") , _("1 hour to 1 day"), ...

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Some thoughts about phpwiki

[Mikhail V. <vla...@ma...>]

Hello, people.

I have installed phpwiki-1.3.10 on my site, and I want to tell you,
what I think about it.

I have tried to make Russian locale for it, to make my own theme, to
add some new special sequences (link --- for mdash, -- for ndash, (C)
for copyright sign e.t.c.).

I found the following difficulties:

1. [:alpha:], [:alnum:] and other character classes works well on my
PHP installation, while phpwiki still tries to use it's buggy
work-around for them.  I want to be able to switch off that
work-around.

2. 'strict' authorization scheme is broken (it tries next
authentication method if previous method says, that user exists, but
password is wrong).  I have fixed this bug by deleting several lines
in WikiUserNew.php (first 'if' statement in function _tryNextPass of
class PassUser)

3. WIKI_NAME_REGEXP is used for both automatic link creation and for
checks for valid user names.  I prefer to apply to user names weaker
conditions, then to automatic links.  I want to be able to specify two
different regular expressions for this two cases.

I am an expierenced PHP programmer and I think, I can help with
development of phpwiki.  At least I can submit Russian locale for it.
My user name at sourceforge is mvladimirov.

--
Best regards
Mikhail Vladimirov <vla...@ma...>

Re: [Phpwiki-talk] Two new queries on search engine activity for AnalyseAccessLog plugin

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

On Mon, February 7, 2005 18:39, Reini Urban said:
> Charles Corrigan schrieb:
>> Here are two new queries that I wrote to analyse search engine activity
>> from the SQL access log. These can be inserted into the
>> AnalyseAccessLog.inc file that I uploaded last week - the insertion
>> point
>> should be just before the final "}".
>
> I see now why you wanted to exclude the queries, but I still don't feel
> comfortable with the seperate .inc file.

The main reason that I wanted to put the queries in a separate file is
that different database engines have different dialects of SQL and I know
that some queries that I have written will only work with MySQL.

The secondary reason for a separate file was to document the query file's
API simply and completely enough to allow non-PhpWiki or even non-PHP
programmers to alter the existing queries to make them work with their
database engine or to add new queries.

Can you suggest an alternative mechanism to achieve what I am getting at?

> That would be the first and only case, and there are several file-based
> methods to list all our plugins (checking for .php, well).
> it violates our current (unwritten) plugin policies.
>
> Also with the name change from mode to queryName.
> I think we want to keep "mode" for consistency.

I thought long and hard about that before making the change as it really
is a change in API. Again, to help people that are not familiar with
programming PHP, I wanted
a) the API name to match the parameter name and
b) the API name to make sense

>
>> The queries contain a list of DNS
>> names for search engine crawlers/spiders/whatever - but this is based
>> only
>> on what I saw in my sites' accesslog. Any additions are welcome.
>
>> } elseif ($queryName=="Search Bots") {
> ...
>>         ."FROM $accesslog "
>>         ."WHERE (remote_host LIKE '%googlebot.com' "
>>         ."OR remote_host LIKE '%alexa.com' "
>>         ."OR remote_host LIKE '%inktomisearch.com' "
>>         ."OR remote_host LIKE '%msnbot.msn.com') "
>>         .($whereConditions ? 'AND '.$whereConditions : '')
>>         ."GROUP BY 'Time Scale', 'Remote Host'";
>
> For search bots you can constrcut the hosts string from
> lib/ExternalReferrer.php

I will look into this, thanks.


>>     $now = time();
>>     $query = "SELECT "
>>         ."IF($now-time_stamp<60, '0 - last minute', IF($now
>> -time_stamp<3600, '1 - 1 minute to 1 hour',
>> IF($now-time_stamp<86400, '2 - 1 hour to 1 day',
>> IF($now-time_stamp<604800, '3 - 1 day to 1 week',
>> IF($now-time_stamp<2629800, '4 - 1 week to 1 month',
>> IF($now-time_stamp<31557600, '5 - 1 month to 1 year', '6 - more
>
> All these are untranslated strings.

Good point, I will see what I can do - to get it "right" may require some
support in the main php file.

regards,
Charles

Re: [Phpwiki-talk] Two new queries on search engine activity for AnalyseAccessLog plugin

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

Charles Corrigan schrieb:
> Here are two new queries that I wrote to analyse search engine activity
> from the SQL access log. These can be inserted into the
> AnalyseAccessLog.inc file that I uploaded last week - the insertion  point
> should be just before the final "}".  

I see now why you wanted to exclude the queries, but I still don't feel 
comfortable with the seperate .inc file.
That would be the first and only case, and there are several file-based 
methods to list all our plugins (checking for .php, well).
it violates our current (unwritten) plugin policies.

Also with the name change from mode to queryName.
I think we want to keep "mode" for consistency.

> The queries contain a list of DNS
> names for search engine crawlers/spiders/whatever - but this is based only
> on what I saw in my sites' accesslog. Any additions are welcome.

> } elseif ($queryName=="Search Bots") {
...
>         ."FROM $accesslog "
>         ."WHERE (remote_host LIKE '%googlebot.com' "
>         ."OR remote_host LIKE '%alexa.com' "
>         ."OR remote_host LIKE '%inktomisearch.com' "
>         ."OR remote_host LIKE '%msnbot.msn.com') "
>         .($whereConditions ? 'AND '.$whereConditions : '')
>         ."GROUP BY 'Time Scale', 'Remote Host'";

For search bots you can constrcut the hosts string from 
lib/ExternalReferrer.php

> } elseif ($queryName=="Search Bot Page Hits") {
>     // This queries for all entries in the SQL access log table that
>     // have a dns name that I know to be a web search engine crawler and
>     // displays the URI that was hit.
>     // If PHPSESSID appears in the URI, just display the URI to the left
> of this
> 
>     $now = time();
>     $query = "SELECT "
>         ."IF($now-time_stamp<60, '0 - last minute', IF($now
> -time_stamp<3600, '1 - 1 minute to 1 hour',
> IF($now-time_stamp<86400, '2 - 1 hour to 1 day',
> IF($now-time_stamp<604800, '3 - 1 day to 1 week',
> IF($now-time_stamp<2629800, '4 - 1 week to 1 month',
> IF($now-time_stamp<31557600, '5 - 1 month to 1 year', '6 - more

All these are untranslated strings.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Two new queries on search engine activity for AnalyseAccessLog plugin

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

Here are two new queries that I wrote to analyse search engine activity
from the SQL access log. These can be inserted into the
AnalyseAccessLog.inc file that I uploaded last week - the insertion  point
should be just before the final "}".  The queries contain a list of DNS
names for search engine crawlers/spiders/whatever - but this is based only
on what I saw in my sites' accesslog. Any additions are welcome.

regards,
Charles

} elseif ($queryName=="Search Bots") {
    // This queries for all entries in the SQL access log table that
    // have a dns name that I know to be a web search engine crawler and
    // categorises the results into time buckets as per the list below
    // 0 - 1 minute - 60
    // 1 - 1 hour   - 3600     = 60 * 60
    // 2 - 1 day    - 86400    = 60 * 60 * 24
    // 3 - 1 week   - 604800   = 60 * 60 * 24 * 7
    // 4 - 1 month  - 2629800  = 60 * 60 * 24 * 365.25 / 12
    // 5 - 1 year   - 31557600 = 60 * 60 * 24 * 365.25

    $now = time();
    $query = "SELECT "
        ."IF($now-time_stamp<60, '0 - last minute', IF($now
-time_stamp<3600, '1 - 1 minute to 1 hour',
IF($now-time_stamp<86400, '2 - 1 hour to 1 day',
IF($now-time_stamp<604800, '3 - 1 day to 1 week',
IF($now-time_stamp<2629800, '4 - 1 week to 1 month',
IF($now-time_stamp<31557600, '5 - 1 month to 1 year', '6 - more
than 1 year')))))) AS 'Time Scale', "
        ."remote_host AS 'Remote Host', "
        ."count(*) AS 'Access Count' "
        ."FROM $accesslog "
        ."WHERE (remote_host LIKE '%googlebot.com' "
        ."OR remote_host LIKE '%alexa.com' "
        ."OR remote_host LIKE '%inktomisearch.com' "
        ."OR remote_host LIKE '%msnbot.msn.com') "
        .($whereConditions ? 'AND '.$whereConditions : '')
        ."GROUP BY 'Time Scale', 'Remote Host'";

} elseif ($queryName=="Search Bot Page Hits") {
    // This queries for all entries in the SQL access log table that
    // have a dns name that I know to be a web search engine crawler and
    // displays the URI that was hit.
    // If PHPSESSID appears in the URI, just display the URI to the left
of this

    $now = time();
    $query = "SELECT "
        ."IF($now-time_stamp<60, '0 - last minute', IF($now
-time_stamp<3600, '1 - 1 minute to 1 hour',
IF($now-time_stamp<86400, '2 - 1 hour to 1 day',
IF($now-time_stamp<604800, '3 - 1 day to 1 week',
IF($now-time_stamp<2629800, '4 - 1 week to 1 month',
IF($now-time_stamp<31557600, '5 - 1 month to 1 year', '6 - more
than 1 year')))))) AS 'Time Scale', "
        ."remote_host AS 'Remote Host', "
        ."IF(instr(request_uri, 'PHPSESS')=0, request_uri,
left(request_uri, instr(request_uri, 'PHPSESS')-2)) AS 'Request
URI' "
        ."FROM $accesslog "
        ."WHERE (remote_host LIKE '%googlebot.com' "
        ."OR remote_host LIKE '%alexa.com' "
        ."OR remote_host LIKE '%inktomisearch.com' "
        ."OR remote_host LIKE '%msnbot.msn.com') "
        .($whereConditions ? 'AND '.$whereConditions : '')
        ."ORDER BY time_stamp";

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

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

Problem in TitleSearch.php using complexer serach patterns. The page 
will never finished

pattern like "Eifel/ -Mineralien -Bilder"

Regards Stefan

[Fwd: [Phpwiki-talk] 24 hours in RecentChanges]

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

Sorry for asking so fast, found it in themeinfo.php

Regards Stefan

[Phpwiki-talk] 24 hours in RecentChanges

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

Hello,

is there a way to display 24 for change date on RecentChanges.
The dates of changes are always shown from 1 to 12 without am and pm. in 
Germany we need 24 hours to display.

Regards Stefan

[Phpwiki-talk] 75% Off for All New Software.

[Heller Katherine<mar...@ya...>]

See attachment message.html

Re: [Phpwiki-talk] RFE - form autocompletion

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

Dan Frankowski schrieb:
> I also asked Mircho about adopting a GPL-compatible license. He said, 
> "It's public domain! Go ahead and use it!" However, the package doesn't 
> have anything *saying* it's in public domain. I'd feel more comfortable 
> if it explicitly declared some GPL-compatible license.

Ok. I just received confirmation that he will license specially for us a 
GPL version, which we'll put into our cvs.
(And probably remove LiveSearch)
-- 
Reini Urban

Re: [Phpwiki-talk] RFE - form autocompletion

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

Dan Frankowski schrieb:
> I added a small section on wikilens code. I apologize for wikilens 
> downtime! It was down from Jan. 10 - Feb. 2 because our machine was 
> hacked. It is back up (yay!). It still needs a little work because the 
> machine has been completely reinstalled, and there are bits and pieces 
> missing or with inappropriate versions.

Good to have it online again!

> I also asked Mircho about adopting a GPL-compatible license. He said, 
> "It's public domain! Go ahead and use it!" 

Good news!

> However, the package doesn't 
> have anything *saying* it's in public domain. I'd feel more comfortable 
> if it explicitly declared some GPL-compatible license.

So should we just write his email into the header? :)

Anyway, his code will need some work to improve performance
for the remote access. But it's the best so far I've seen.
So he will probably be bought out by Google, so that his website will go 
down also.
(As mozdev.org apparently did recently.
Or is it really only the denial of service attack?
Or is some reaction to the recent buzilla vandalism?
Or just google's buyout?)

http://66.102.9.104/search?q=cache:B7q9RqGxAI8J:www.mozillazine.org/talkback.html%3Farticle%3D5960+what+happened+to+mozdev+2005&hl=de
http://gemal.dk/blog/2005/01/25/bugzilla_attack_on_bugzillamozdevorg/
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/