I'm trying to do two queries, does this code look right?
bchocitation is a table that holds information about citations we are
using. Ultimately I want a list of all citations that are not linked
to. My plan was to get the list of citation titles, and compare them
against titles in pagelinks, if the title does not appear in pagelinks
then it isn't linked to.
//SELECT page_title FROM bchocitation, page WHERE
bchocitation.page_id=page.page_id;
$results = array();
$dbr =& wfGetDB( DB_SLAVE );
$res = $dbr->select(
array( 'bchocitation', 'page'), //from
'page_title', //select
array('bchocitation.page_id'=>'page.page_id'),//where
__METHOD__,
array() //extras
);
while ($obj = $dbr->fetchObject($res)) {
$results[] = $obj;
}
$dbr->freeResult($res);
//SELECT pl_title FROM pagelinks WHERE pl_title='$title';
$result = "";
$dbr =& wfGetDB( DB_SLAVE );
$res = $dbr->select(
'pagelinks', //from
'pl_title', //select
array('pl_title'=>"'$title'"),//where
__METHOD__,
array() //extras
);
while ($obj = $dbr->fetchObject($res)) {
$result = $obj;
}
$dbr->freeResult($res);
Any help is much appreciated!
-Courtney Christensen
Hi all,
We have a mediawiki site for our staff members to document their
technical works, therefore we'd like to upload some source codes or
patch files other than images or .doc and .pdf format. For example,
.diff, .patch, .tar.gz, .xml, .conf, .sh, .pl, .py, .c.
However we are not quite sure if there is any security concern about
this issue. Does anyone experience this before?
Thanks
Eric
I have a series of inputboxes on my Main Page
(http://seventh-star.net/wikific) which allow people to create or search
for certain articles. I upgraded to 1.11 the other day, but I noticed
that post-upgrade, the buttons now have the HTML code for the
greater-than and less-than angle brackets next to what should be the
STANDALONE text of the buttons, "create article," "search full text" and
"search exact." I've already looked at all the appropriate templates to
see if it was something I could easily fix, but I didn't find anything.
Is there any way I can fix this, or is it particular to the Inputbox
extension responding to the upgrade?
-Azurite
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Dear list,
we are using a MediaWiki for internal documentation. Sometimes we would
like to upload text files (automatically generated equipment logs).
Ideally they should be displayed as preformatted text, with no
interpretation at all (the files can contain "<", ">", ...).
Is there an easy and comfortable way to do this?
Best, Andreas
- ---------------------------------------------------------------------
Dr. Andreas K. Huettel tel. +31 15 27 88102 (univ.)
Molecular Electronics and Devices
Kavli Institute of Nanoscience Delft
Delft University of Technology
PO Box 5046, 2600 GA Delft
The Netherlands http://www.akhuettel.de/research/
- ---------------------------------------------------------------------
Please use GNUPG or PGP for signed and encrypted email. My public key
can be found at http://www.akhuettel.de/pgp_key.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFG7ZiqL+gLs3iH94cRA6H7AJ9KpgbB5hP324MiWtfsS8uCJAc1XgCfc3Cx
abxv+b4EwGC3PzTOK6d/tWU=
=2ipN
-----END PGP SIGNATURE-----
On 16/09/2007, Matt Weaver <Matt.Weaver(a)westlakelibrary.org> wrote:
>
> Hi, I just installed MediaWiki 1.9, but it will not allow me to log in using the info I gave when I set it up. It rejects my password. In my "localsettings.php" file, it gives the proper password: just to be sure, I even copied the password from localsettings.php and pasted it into the login window.
The installer tends to accept two sets of user credentials (it will
accept up to three, but it's often the case that the third doesn't
need to be provided) - a username and password for the database
connection, for everyday use, and a username and password for the
sysop account.
These are *two separate sets of credentials* which are stored in
completely different locations. When you log into MediaWiki, you need
to use the sysop credentials. [Apparently, people keep forgetting to
read the box that these are entered into, or get confused, so we could
potentially make this clearer.] By default, the sysop username is
"WikiSysop", but if this isn't the case, then a quick glance at the
"Special:Listusers" page ought to reveal a user with sysop and
bureaucrat permissions; this is the account you want.
Of course, this isn't a hell of a lot of use if you don't know the
password for said account, so the likelihood is that, once you've got
it, you'll need to use maintenance/changePassword.php, or manually
update the database (Google "MediaWiki password hash" for dozens of
pointers) to reset the password. You can then use the RenameUser
extension to rename the account, if you'd like.
Rob Church
Hi, I just installed MediaWiki 1.9, but it will not allow me to log in using the info I gave when I set it up. It rejects my password. In my "localsettings.php" file, it gives the proper password: just to be sure, I even copied the password from localsettings.php and pasted it into the login window.
Any would be appreciated.
Hi,
I am working on a MW instance where we batch load a ton of data from
an external database. We have about 50,000 records, each of which
becomes a MW page. So far so good (we use pywikipedia to load the
data). Now it comes to the issue of consistency...
A) The external database may change independently of the MW.
B) The MW may change independently of the external database.
Ignoring problems related to B (for the moment), we can propose the
following solution to problem A;
1) As each 'record page' is loaded into the MW (for the first time),
it is put into a special category ('Category:External DB record page'
for example).
2) We can list all 'record pages' using a direct query over the MW
database (or using pywikipedia?)
3) We can delete all the pages in our list from the MW.
4) We can load all the pages again from the external database.
The above is clearly inefficient. Even if we only run an 'update' job
every month - its a lot of needless work. So, I want to propose the
following;
1) After loading as before, we update 'cl_timestamp' in the
categorylinks table to the value of the 'last modified' field of the
data in the external database.
2) We can list all 'record pages' using a direct query over the MW
database, including the 'last modified' timestamp (which is now
'cl_timestamp').
3) We can synchronize pages that have changed based on newer 'last
modified' timestamps in the external database (and additionally delete
/ add entries as necessary).
The latter method has the advantage of only requiring incremental
updates, which will be much faster in our case (slow data turnover).
Question 1) Will tinkering with 'cl_timestamp' have any adverse
effects? The effect on DPL 'order=categoryadd' is actually desired in
our case.
Question 2) Any way to do this without direct database access? For
example, could we write a template to 'update categorized date' given
a page name and a category name? Does pywikipedia have functions to
interact with special pages? Can you point me at a similar template?
I don't want to put the 'last modified' field in the page, because it
would involve downloading and parsing all the content. Rather I would
like to query one field of the DB. Using 'cl_timestamp' in this case
is just a hack that seems to fit. Of course I could just make a new
table in the database to store this data, or keep an accurate list of
the state of the MW locally. However, none of these solutions seems
quite satisfactory.
Any feedback on the above would be most welcome.
All the best,
Dan.
It seems that the only solution was to restart the DB Server... sic...
A tipical Windows like solution...
mah...
Giuseppe Briotti
--
Giuseppe Briotti
g.briotti(a)mclink.it
"Alme Sol, curru nitido diem qui
promis et celas aliusque et idem
nasceris, possis nihil urbe Roma
visere maius."
(Orazio)