We have "Add HTML Meta and Title" extension installed. (
http://www.mediawiki.org/wiki/Extension:Add_HTML_Meta_and_Title). We can
easily "ADD" tags, but we don't see a method for removing them, or even
modifying them. I don't even know where the information we add is being kept
(Though i am sure its probably in the database, i have looked, and fear it
might be kept in the "BLOB" blocks, and i have no idea how to vew/modify
those fields, or if i would even want to. Someone mind looking at this
extension and helping me understand where the data is kept, or how to
remove/modify what the extension does to a page? What is completely
confusing is that the Extension lets you use the Page Editor (i don't know
the proper name) where the content of the page is created to add, using some
special formatting. But once you save, the text you enter disappears, so you
can't change it.
Hello,
I am have a problem embedding more than one tag extensions in any given post on my wiki. wiki version 1.16
Both tag extensions work fine by them selves but when ever I add the second one it causes errors or I just get a white page.
I am using <servers/> and <contact/> to embed the extensions. I am guessing that when I add the second extension I am causing some type of problem with
a global variable or some kind of name space issue. I have included all the code for the two extensions. any help would make my day!
Thanks!
###ContactTag.php###
<?php
$wgHooks['ParserFirstCallInit'][] = 'ContactTag::setup';
$wgAutoloadClasses['ConatctTag'] = dirname( __FILE__ ) . "/ContactTag_body.php";
###ContactTag_body.php###
<?php
// Create hello tag for the Wiki
class HelloTag {
const NAME = 'contact';
static function setup() {
// The entry point. Associates the tag with a function.
global $wgParser;
$wgParser->setHook(self::NAME, array('ContactTag', 'render'));
return true;
}
static function render() {
//required for DB connection
require "db_mysql.inc";// defined in /etc/php.ini path: /usr/lib/php/include/
require "define_hosts.php"; // defined in /etc/php.ini path: /usr/lib/php/include/
// Connection Parameters
$em7_g3 = new DB_MySQL;
$em7_g3->Host = $em7_host;
$em7_g3->User = $em7_user;
$em7_g3->Password = $em7_pw;
$em7_g3->Database = "biz";
$em7_g3->connect();
$ris = new DB_MySQL;
$ris->Host = $storm_host;
$ris->Database = "sugarcrm";
$ris->User = $storm_user;
$ris->Password = $storm_pw;
$ris->connect();
//Get end of URL remove _ from client name for DB query
$endURL = $_GET["title"];
$phrase = $endURL;
$healthy = array("_");
$yummy = array(" ");
$newphrase = str_replace($healthy, $yummy, $phrase);
//Run DB query and run though loop to get DB client data
if ($newphrase) {
$q = "Select v.first_name, v.last_name, f.email_address from contacts AS v
Left join accounts_contacts AS s ON v.id = s.contact_id
Left join accounts AS a ON a.id = s.account_id
Left join email_addr_bean_rel AS e ON v.id = e.bean_id
Left join email_addresses AS f ON f.id = e.email_address_id
where a.name ='$newphrase'";
$ris->query($q);
$acnt = "";
$table ="<table border='4'>";
while ($ris->next_record()) {
$company = $ris->f("first_name");
$device = $ris->f("last_name");
$active = $ris->f("email_address");
//$ip = $ris->f("ip");
$acnt = $acnt + 1;
if ($company) {
if ($acnt){
$addr_list[$acnt] = "<tr><td>$company</td><td>$device</td><td>$active</td><td>$ip</td></tr>";
$string = $string.$addr_list[$acnt];
}
}
}
$tableEnd="</table>";
return $table.$string.$tableEnd;
}
}
}
###ServerTag.php###
<?php
# Credits
$wgExtensionCredits['other'][] = array(
'name' => 'ServerTag',
'description' => 'Print All Servers Based On Client Page Name.',
'version' => '1.0');
# Set up the hook, using different logic depending
# on the version of MediaWiki
if (defined('MW_SUPPORTS_PARSERFIRSTCALLINIT')) {
$wgHooks['ParserFirstCallInit'][] = 'ServerTag::setup';
} else {
$wgExtensionFunctions[] = 'ServerTag::setup';
}
# Autoload the implementation class
$wgAutoloadClasses['ServerTag']
= dirname( __FILE__ ) . "/ServerTag_body.php";
###ServerTag_body.php###
<?php
class ServerTag {
const NAME = 'servers';
static function setup() {
global $wgParser;
$wgParser->setHook(self::NAME, array('ServerTag', 'render'));
return true;
}
static function render() {
//required for DB connection
require "db_mysql.inc";
require "define_hosts.php";
// Connection Parameters
$em7_g3 = new DB_MySQL;
$em7_g3->Host = $em7_g3_host;
$em7_g3->User = $em7_g3_user;
$em7_g3->Password = $em7_g3_pw;
$em7_g3->Database = "master_biz";
$em7_g3->connect();
//Get end of URL remove _ from client name for DB query
$endURL = $_GET["title"];
$phrase = $endURL;
$healthy = array("_");
$yummy = array(" ");
$newphrase = str_replace($healthy, $yummy, $phrase);
//Run DB query and run though loop to get DB client data
if ($newphrase) {
$q = "SELECT company, device,master_dev.legend_device.active, master_dev.device_ip_addr.ip from master_biz.`organizations` left join master_dev.legend_device on master_biz.`organizations`.roa_id = master_dev.legend_device.roa_id left join master_dev.device_ip_addr on master_dev.legend_device.id = master_dev.device_ip_addr.did where company = '$newphrase'";
$em7_g3->query($q);
$acnt = "";
$table ="<table border='4'>";
while ($em7_g3->next_record()) {
$company = $em7_g3->f("company");
$device = $em7_g3->f("device");
$active = $em7_g3->f("active");
$ip = $em7_g3->f("ip");
$acnt = $acnt + 1;
if ($company) {
if ($acnt){
$addr_list[$acnt] = "<tr><td>$company</td><td>$device</td><td>$active</td><td>$ip</td></tr>";
$string = $string.$addr_list[$acnt];
}
}
}
$tableEnd="</table>";
return $table.$string.$tableEnd;
}
}
}
Mike Cody
Systems Administrator
RELIAM
(310) 348-9700 x 2 ( Support )
(310) 348-9797 FAX
----
Blog: http://www.reliam.com/news/reliam_blog
Twitter: http://www.twitter.com/reliam
Facebook: http://www.facebook.com/reliam
----
The format of $wgValidSkinNames has been changed. Previously it had been
`$wgValidSkinNames[key] = name;` but now it's `$wgValidSkinNames[key] =
ClassNamePostfix;`
In essence the code that creates a skin class has now been changed to
try to create a class named "Skin{$wgValidSkinNames[$key]}".
This change is because of a bug with skins that are autoloaded.
Previously when you defined a skin like `$wgValidSkinNames["bluebook"] =
"BlueBook";` MW would try to load SkinBluebook rather than SkinBlueBook.
This worked in core because we didn't autoload skins and instead did a
`require_once( "{$wgStyleDirectory}/{$wgValidSkinNames[$key]}.php" );`,
because php's class system is case-insensitive SkinMonoBook always
loaded fine, however this wasn't the case for extension based skins
which used our case-sensitive autoloader.
Keep this in mind when making autoloaded skins if you want pre-1.18
compatibility you may have to add two autoloader lines, one for
SkinBlueBook and another for SkinBluebook.
Legacy skins are depreciated. The old skin system inside 'Skin' that
powered the old skins CologneBlue, Nostalgia, and Standard/Classic has
been dropped and replaced by a deprecated SkinLegacy system based mostly
on SkinTemplate. New skins should all be SkinTemplate based, SkinLegacy
only exists to support the 3 core skins that were ported, it may be
eliminated from core in the near future along with the legacy skins.
Note that this means a lot of methods like Skin::editThisPage() that
were never meant to be used by SkinTemplate are no longer available, if
you used $sk-> methods check over your skin to make sure it's not
throwing errors because you were using outdated methods.
We now have a context system, if building a skin for 1.18+ please ensure
that you use ->getUser(), ->getLang(), ->getRequest(), and
->getOutput(), instead of $wgUser, $wgLang, $wgRequest, and $wgOut.
The linker is now static, skins wishing to use linker methods should
migrate away from calling them on $sk-> and use Linker:: properly.
Note that doEditSectionLink is now explicitly part of Skin, it's no
longer a Linker method, if you're using it take note of that. As a
result of this and some parser changes skins can now customize the
editsection link within their own skin by overloading the
doEditSectionLink method. Note that if you did this before 1.18 you
would pollute the cache and end up with other skins having your
customizations sometimes, and your skin losing it's customization
sometime. Make note of that if you override doeEditSectionLink as you
may want to include a conditional to leave it alone if your skin is used
in a release before 1.18.
We have two new pieces of information for skin, a relevant title and
relevant user. Relevant title is used when doing things like generating
tabs, special pages like Special:Movepage use it to make skins display
the tabs for pages they are relevant to instead of making them suddenly
disappear on the user (1.19 or later may have a more robust way of
handling tabs though). Relevant user is similar, pages like
Special:Contributions use it so things like the block link in the
toolbar are the same as when visiting a userpage.
The specialpageattributes key is no longer needed in your skin if it's
meant for 1.18+, there's better code in core now handling lang/dir for
the body.
The printfooter and debughtml have been pulled out of bodytext and are
now in separate printfooter and debughtml keys (I think I need to make
not of that in my own skins).
((I have some issues with this change (not mine), the situation may
change a little before release if I try to backport something))
The "Login / create account" link can now be split into two separate
"Login" and "Create account" links by user configuration using
$wgUseCombinedLoginLink. For now it defaults to the same behavior as
before. Skins which have a reason to need one behavior or another (eg:
turning the links into buttons and wanting to make sure they're both
there) can override the useCombinedLoginLink method and return either
true (combined) or false (split) to override the configuration.
A great one now. Sort of replacing content_actions we have a new
content_navigation tplkey. The Vector code generating it's own
hierarchical content_actions has been pulled out of vector and merged
into SkinTemplate, any skin that wants to take advantage of the better
organized namespace/variants/views/actions categorization of our tabs
can now use content_navigation to take advantage of them. Skins using
content_actions will still work, the content_actions array is created
based on content_navigation now, the content_navigation arrays are
annotated with information like 'primary' (vector uses this to stop
collapsing of tabs into the menu on small screens) and 'redundant' for
tabs like 'read' which tells the content_actions code that the tab is
redundant and shouldn't be included in content_actions.
Extensions which used SkinTemplateTabs and didn't add a
SkinTemplateNavigation hook will stop working as the
SkinTemplateNavigation hook has completely replaced SkinTemplateTabs
(ok, I admit I think there's an old SkinLegacy hack that still uses
SkinTemplateTabs for the tabs in legacy code). Extensions that had
issues with vector's code not including replacements for the
SkinTemplateBuildContentActionUrlsAfterSpecialPage and
SkinTemplateContentActions hooks will be happy to know that
content_actions now has equivalent replacement hooks
SkinTemplateNavigation::SpecialPage and
SkinTemplateNavigation::Universal which you can add. If you use these
hooks in new code, and don't need pre-1.18-non-vector compat, and aren't
worrying about SkinLegacy still using a SkinTemplateTabs hack you don't
need to include the old hooks since content_actions is extracted from
content_navigation.
There is new message fallback code in the i18n system. Many of the
messages for tabs like 'move' can be overridden per-skin with messages
like 'vector-action-move', 'modern-action-move', etc... If not defined
they will fallback to the normal message. Vector had some message
customizations before because of changes from monobook in how it handled
tabs so this was added so we'd have a way to keep those without doing it
in an ugly hacky way. Other skins can now include similar customizations
and individual wiki can include per-skin message overrides if there are
things like the edit button you want to customize the message for but
have an issue where it looks fine in one skin but messes up the
intuitiveness of another.
Skin QuickTemplates now have a $this->getSkin() method they can use
instead of fumbling around with $this->data['skin'].
We have a new BaseTemplate class that extends QuickTemplate, it includes
a number of helpers for skins and you can start to take advantage of
them in a 1.18 skin by extending from BaseTemplate instead of directly
from QuickTemplate.
This can kill a lot of ugly boilerplate from skins like the huge
boilerplate for personal_urls and content_{actions,navigation}. Links
and list items for many of the common tpl key arrays we have (ie:
content_{actions,navigation}, etc...) where there are arrays like
personal_urls that aren't in a format these helpers can handle we have
helpers like getPersonalTools that will give you an array in the right
format. The search input and search button have helpers to simplify them
too (I couldn't come up with a good helper for the search form opening
code though). You can replace the mess of bottomscripts, reporttime, and
debug trail in your skin now with a simple `$this->printTrail();`. And
those remembering my footerlinks and footericons code just introduced in
1.17 will be happy to know there are helpers here to simplify the
boilerplate for those. Also that horrible ugly massive boilerplate for
the toolbox you have to copy into any skin, we now have a getToolbox
helper that returns an array that will work with the mageListItem
helper, it also has a new hook BaseTemplateToolbox that will work on
that rather than have you output raw html not customized by skin. So
please do start using it in skins, it would be nice to deprecate those
html hooks and have extensions stop using them.
----
1.19 is in active development so there isn't much added yet, but I do
have a nice quick note on what is in there now.
Vector contains a pile of css for content styling which was basically
copied from Monobook and modified slightly. That css has now been
stripped out and put into three stylesheets in common/:
commonElements.css: This stylesheet contains all your basic elements;
Paragraphs, Links, Headers, etc... If you want anything from the common
styles you'll want this at least.
commonContent.css: This stylesheet contains more complex things which
are contained within the content area, right now it contains things like
the TOC and the frames that are wrapped around images. These are things
you might not want default styles for in your skin and might want to
customize in ways that having pre-existing styles could get in the way
of (it's easier to override simple styles by commonElements than it is
do undo the styling of the entire toc for example).
commonInterface.css: This stylesheet contains some extra common stuff
between MonoBook and Vector. These are tied to patterns in ids and
classes for things like the usermessage, catlinks, etc... which are
outside of the bodytext and the skin may decide on the ids and classes
for. If you're making a skin that sticks with the MonoBook/Vector
patterns of laying out and id/classing the content area you can include
this stylesheet to get some of the common styles.
There are a few notes on opting-in to this in your skins:
- I haven't figured out how to deal with the icons for external links
(the https, audio, etc... icons) yet, MonoBook and Vector use different
icons so while the pattern is common the images aren't. So they aren't
actually the same stylesheet wise. This may end up as a separate to
include stylesheet later on.
- When opting in you'll need to add a class="mw-body" somewhere into
your skin to define the area where content css stylings for things like
links will apply. In MonoBook this is on the same element as
#bodyContent and in Vector it's #content.
- To use these stylesheets include them into your ResourceLoader
'styles' array, that way it all gets combined into a single css file for
your skin.
-- I didn't make this a separate module because we include
&skin=skinname into the /load.php call, that means that even if I make
these modules they aren't reused between different skins. Hence there is
no value in having them in a separate module and it's better to include
them in the skin's own module where they'll be combined into a single
css file.
- With link styles and one or two minor changes from MonoBook to Vector
the Vector difference was preferred since Vector has replaced MonoBook,
MonoBook is now essentially outdated, and new skins will likely be
Vector based rather than MonoBook based. If you want things to look a
little more old and monobook like you may want to add some overriding
css in your own styles like the rules that monobook adds in it's own css
for links.
- MonoBook and Vector use different bullet images for ul {}, since
they're embedded images and would end up inlined in skins that might
override them I opted out of including them in the elements stylesheet.
If you want a list bullet image you'll have to embed one into your own
stylesheet. We have an old .gif that looks like the one in MonoBook
inside common, but the Vector one right now is only in vector. Though I
may contemplate moving that to common.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
MediaWiki 1.17 contains some new features for skin authors, most of my
skin system reform was backed out for later releases so it's only some
small stuff for now:
I'm not going to go over the ResourceLoader here since I didn't author
it. But do make note of it, skins should update themselves and take
advantage of the resource loader. If you ever thought that your skin's
css file was far too big this is now your chance to split it up into as
many cleanly separated stylesheets and have the resource loader combine
them all into a single stylesheet automatically so you can get the
organized code while keeping your skin nice and fast.
Also make note to use @embed rules and @noflip. You don't need a
separate rtl stylesheet anymore (though do test your skin in rtl
environments so you know what rules you need to @noflip). You don't need
to depend on css sprites anymore since images are embedded into
stylesheets with @embed. However do try to avoid using multiple @embed's
for the same image, if you use the same url() in multiple places in your
css try to consolidate them all into a single combined css rule.
Otherwise when you use @embed you'll be unnecessarily bloating your css
since they're now inline and not combined into one by the browser's cache.
Footer links:
Previously the list of links in the footer was hardcoded into individual
skins, there's now a new array managed by the skin template.
Skin authors can now use $this->data['footerlinks'] and it's sub-arrays,
the way to output the links is generally the same values in the
footericons sub-arrays are tpl keys.
Extensions can now tweak the list of footerlinks by registering a
SkinTemplateOutputPageBeforeExec hook, modifying the one of the
footerlinks sub-arrays in it by adding a new key, and setting a new key
of the same name on the $tpl.
One of these days the footericons may be replaced with a better system
that'll actually be customizable by system message config, but for now
for compatibility reasons this is what we've got.
Footer icons:
The previous copyrightico and poweredbyico keys are now depreciated in
favor of a new footericons setup. The icons are accessible by
$this->data['footericons'] which is populated from $wgFooterIcons, with
some extra guarantees like if "src" is set a width and height will
always be set so you don't need to test for them. There is a
Skin::makeFooterIcon method skins can use to simplify the creation of
the actual footer icons/text, actually I recommend that every skin makes
use of this method with the same kind of boilerplate used by
monobook/vector (for icons) or modern (for text).
Users can now use $wgFooterIcons to customize the icons in the footer.
Kill off the copyright icon, powered by, add an icon to wiki you host in
a wiki farm, add icons for someone responsible for managing your wiki,
etc... Extensions that want to customize this can look at how it's done
in SMW. However do so very sparingly, ONLY if you're a really big
extension like SMW that your users won't mind an icon showing up for (or
of course if your extension's only purpose is to customize that, eg: an
extension that creates a ui to let sysops add icons to the footer). If I
see extensions start to abuse this and bloat the footer with vanity
icons I'll personally go into svn and delete the icons from each extension.
Skin and Extensions authors and users can check the $wgFooterIcons
documentation for info.
Skins also have access to Skin::getCommonStylePath and
Skin::getSkinStylePath. These are helper methods you can use if you have
a need to include the url for a skin or common resource within your skin
itself. Mostly if you're doing something like inserting an image using
an actual <img> rather than a background-image.
Skins can override a new addToBodyAttributes method if there are any
attributes or css classes not in the built-in headelement <body> tag
that they want to be there.
By the way if you haven't already, please do start using the headelement
introduced in 1.16.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Hi, all,
I wrote earlier this week about the issue we were having with uploading and downloading Office docs to the wiki (it was zipping .docx, .xlsx, and .pptx files on upload and therefore not able to open them on Windows machines on download). I'm happy to report that simply upgrading to 1.17 appears to have resolved the issue!
It's mentioned in the release notes, http://www.mediawiki.org/wiki/Release_notes/1.17, under "Bug Fixes for 1.17," https://bugzilla.wikimedia.org/show_bug.cgi?id=23688.
Thanks to everyone who responded to my repeated pleas for help on this issue!
Nina
Nina McHale, MA/MSLS
Assistant Professor, Web Librarian
University of Colorado Denver, Auraria Library
Facebook & Twitter: ninermac
http://milehighbrarian.net<http://milehighbrarian.net/>
Hello,
I've tried to upload a file today, and got an error message saying the
extension of the file doesn't correspond to the mime type.
It was still working 3 weeks ago, and I didn't make any change to the wiki.
Version is 1.16.0. I checked the Localsettings file and it's still ok.
Any idea where this could come from?
Thanks
--
*André Meunier*
Documentaliste et responsable IT
Bibliothèque des Sciences de la Vie
Téléphone : 04 366 2173
http://www.libnet.ulg.ac.be/mede/