User talk:Pathoschild
![]() |
Hi! My name is Jesse. I was an active editor and administrator here many years ago, but nowadays I quietly write scripts and make the occasional edit. See my Meta user page for more info. (Older messages are in the archives).
CrossActivity
Hi,
Your CrossActivity script lists the last date that I performed a bureaucrat action here on Wikisource. But as you know I am not a bureaucrat. I had a look, and that day I put someone in the autopatrolled group. It seems that anything in the User Rights Log is being treated as a bureacrat action. I'm not fussed if you don't consider this a bug worth fixing. I just thought I would mention it.
Hesperian 12:21, 4 March 2010 (UTC)
- Hi Hesperian. I know about that issue; administrators could not set any rights when it was written. I'm not sure how easy this will be to fix, but I will look into it when I rewrite the script using the new tools framework I'm working on. —Pathoschild 20:45:34, 04 March 2010 (UTC)
- Roger that. Hesperian 23:14, 4 March 2010 (UTC)
cleanup()
Hi,
I don't know how aware you are but a little group of us have been building scripts that we register in the sidebar using your regexTool() function. Billinghurst is talking about putting the main one, cleanup(), into a gadget. This is, I think, a good idea, but I have a couple of concerns. One is that you have not "published" regexTool() and could change it at any time. Another is that at the moment these scripts only work because we have your Custom regex gadget turned on. It would help if you would say "Yes, I am aware that you have been using this function, and I am happy to consider it a public interface, and I promise to try not to break it when I tweak my code, and if you want to access it directly without installing Custom regex then you should add this import line to your script: ...."
Hesperian 11:45, 13 March 2010 (UTC)
- Hi Hesperian. I search for scripts using the framework before I commit any breaking changes. If you list your script pages in the script's user list, I'll make sure to update them if needed. There's an upcoming rewrite that will modularize the script into a reusable object; this will make it possible to use individual components without necessarily using the whole script. It will also be possible to have multiple instances interacting seamlessly, so you could (for example) have a separate instance for cleanup() just in case the user doesn't have the framework enabled. —Pathoschild 21:35:11, 13 March 2010 (UTC)
Relocating the regex form for the Page: namespace
The location of the custom regex form in the Page: namespace is a little problematic as it appears beside the image, and hence pushed down the text box. I cannot work out the id name of the box/form for custom regex, so would you mind telling me how to juggle the sections around in my monobook.css to either put it after the these two sections and before the edit, or before the image alternatively before the toolbar so that I am not losing the side by side aspect. Thanks. — billinghurst sDrewth 02:59, 19 March 2010 (UTC)
- Hi sDrewth. I tried adding code to make it configurable, but an issue in the underlying framework was causing infinite loops in Chrome. I'm planning a rewrite to jQuery as soon as I finish my current rewrite of Ajax Sysop and StewardScript, so I'll make sure to make that configurable when I do. —Pathoschild 00:46:46, 20 March 2010 (UTC)
- Fair call. I'll be patient. — billinghurst sDrewth 02:28, 20 March 2010 (UTC)
MediaWiki:Gadget-TemplatePreloader.js and year parameter
I tried to look to add year to the Gadget, if there was no forward slash in wgTitle, however it seems that I am just a confused bunny in the spotlights. My revert is [1]. Your slap and tickle would be appreciated, and apologies ahead of time for my inabilities. — billinghurst sDrewth 01:16, 10 April 2010 (UTC)
- Added; you did it correctly. :) —Pathoschild 01:28:54, 10 April 2010 (UTC)
Pathoschild: You have protected this article. However, it needs an amendment: Category:Poems to Category:Early modern poetry. Can you do that please? Thanks.--Longfellow (talk) 17:17, 6 May 2010 (UTC)
- Done; thanks. —Pathoschild 19:02:54, 06 May 2010 (UTC)
Mysterious work of French history
Hi Pathoschild—I see you're a speaker of French, so if you have the inclination to do some historical research, I have a challenge for you. I'm proofing Page:Lectures on Modern History.djvu/189, by Lord Acton. It was written around 1900. He refers to a work called Histoire Générale, and calls it "new" (whether that means "subsequent" or "recent", I don't know). Other than that, however, he gives no further information about it. Previously in this chapter he refers to French authors Guizot and Berdier. I can't find much about Berdier, but Guizot wrote something with a similar title, fr:Histoire générale de la civilisation en Europe, in 1828 (according to the 1911 Britannica). According to that same article, Guizot again applied himself to history later in life (1850s and '60s), but does not mention a re-release of his Histoire Générale.
I suppose it's possible that Acton is referring to an English translation of the work, but this seems highly unlikely, as Acton spoke French, and refers to it by its French title.
If you have the time and inclination, I'd be interested in knowing if my conjecture is correct. Perhaps there is more in-depth material on Guizot somewhere, or a French edition of his work dating from the late 19th century? Or perhaps it's another author entirely? Let me know if you discover anything—thanks! —Spangineerwp (háblame) 20:27, 19 May 2010 (UTC)
- Hi Spangineer. I looked into it, but couldn't find the work or passage he's referring to. I didn't find any references to the Huguenots in the Histoire générale de la civilisation en Europe, and couldn't find any other Histoire générale backing his statement. Unfortunately I found the subject and known information too vague to pinpoint his source. —Pathoschild 01:09:11, 20 May 2010 (UTC)
- Ah well; thanks for the effort! That's the problem with Acton; he read everything, and thinks everyone else does too =). —Spangineerwp (háblame) 14:23, 20 May 2010 (UTC)
Dumb question
Looking at http://en.wikisource.org/w/api.php?action=query&meta=siteinfo&siprop=general%7Cnamespaces%7Cnamespacealiases%7Cstatistics We have a weird setup that some of the namespace don't have subpages, yet the equivalent talk pages do. From my viewpoint that means that we don't have alignment between talk pages in Template: ns if we put a / in it. — billinghurst sDrewth 07:38, 1 July 2010 (UTC)
Help:Licensing compatibility is mostly created by you pulling bits together though some of the discussions listed. The referred discussions seemed to me to not consider {{PD-EdictGov}}, so I have started that conversation at Wikisource:Possible copyright violations#Help:Licensing_compatibility#Non-derivative to discuss. (Just so you know) — billinghurst sDrewth 10:09, 20 July 2010 (UTC)
- *nod*. —Pathoschild 16:56:14, 21 July 2010 (UTC)
Would you be so kind (& clever) to make Template:Disambiguation colour-code its top box to align with the namespace of its appearance. Off the top of my head, I think that the only requirement for change would be the Author: namespace, however, I could be wrong. Thanks if you can. — billinghurst sDrewth 15:52, 24 July 2010 (UTC)
- Hi sDrewth. Do you have a table or template listing those colours? —Pathoschild 16:54:01, 24 July 2010 (UTC)
- Oops (excuse delay). There is a big splash of this discussion at Wikisource:Scriptorium#Header templates with the colours shown; though in consideration of the occasional changes, is this something that we would look to partially set through common.css which I believe happens with class=headertemplate, hence changes are further reflected (I think I am making sense though maybe I am not). — billinghurst sDrewth 14:10, 12 August 2010 (UTC)
- (Sorry for the delay; I'm temporarily without Internet access at home.)
- I added a CSS class to the template, so it's now possible to add per-namespace styles on disambiguation templates. For example, the following in Common.css will apply the author colours to disambiguation templates in the author namespace, as well as the author template:
.authortemplate,
.ns-102 .disambiguation .headertemplate {
border: 1px solid #BEA2A2;
background-color: #E4D8D8;
}
- Alternatively you can make all header instances in the Author namespace adopt author colours with
.ns-102 .headertemplate
. —Pathoschild 17:52:46, 16 August 2010 (UTC)
- Alternatively you can make all header instances in the Author namespace adopt author colours with
Adding regex search links to left sidebar
Hi. Hope that your connectivity is going to be returned to you soon, and that this note finds you, and she who must be obeyed, well. Whenever you have the time, I am interested in looking to get the ability to put some custom searches into my left toolbar, in near the rmflinks, and not sure how to code the links. I am looking to do a series of searches based on {{PAGENAME}} {{BASEPAGENAME}}; and others for when I am building author pages. While it is not exactly a regex, I was looking for guidance on how to construct these search links. Thanks. — billinghurst sDrewth 13:44, 27 August 2010 (UTC)
- I'll poke you about it on IRC. —Pathoschild 21:00:09, 29 August 2010 (UTC)
regexToolWithShortcut()
Hi Pathoschild,
I forked regexTool()
into regexToolWithShortcut()
, so that I could invoke some of my scripts through keyboard shortcuts. I'd prefer to see this functionality somehow merged into your menu framework, though that is of course entirely up to you. When you have time, please have a look at User:Hesperian/vector.js and let me know what you decide.
Hesperian 04:15, 14 September 2010 (UTC)
Common.js ... Secure links and BilingualLink
Some help. After a post to wikitech-l about secure links, in reply Platonides said to look at commons:MediaWiki:Common.js/secure.js and "<=> links from [Extension:DoubleWiki Extension] ... That's a bug in BilingualLink() function in MediaWiki:Common.js. Talk with Pathoschild." I was going to link import the script into the Common.js file, then thought that this may not have been a good practice, so it is added though commented out. Would you be so kind to put onto a TO DO WHENEVER list a review of the script, and a poke ab BilingualLink()? Thanks if you can. — billinghurst sDrewth 01:00, 5 January 2011 (UTC)
- Fixed. —Pathoschild 06:00:48, 10 January 2011 (UTC)
- Was there an opinion on the practice of imports into common.js. Thanks. — billinghurst sDrewth 10:39, 10 January 2011 (UTC)
- Importing scripts into Common.js is fine, and commonly done on some wikis (like enwiki). —Pathoschild 23:01:27, 10 January 2011 (UTC)
Re:Page numbering
Nope, that was an oversight. Correcting now, thanks. --Eliyak T·C 02:46, 16 January 2011 (UTC)
Thanks
Re edit JeepdaySock (talk) 17:09, 16 February 2011 (UTC)
Dada Manifesto (1918, Tristan Tzara)
Your deletion of Dada_Manifesto_(1918,_Tristan_Tzara) was ill advised, see the explanation http://copyright.cornell.edu/resources/publicdomain.cfm
Now if you can find a copyright on the English translation, that may have had some merit, but in the future, do try and either leave some half decent notes or cite where you are getting your idea as to how the copyright is in effect.—unsigned comment by 69.171.164.144 (talk) .
- The process to a request undeletion, or the review process, is through Wikisource:Possible_copyright_violations. Usually it is through that process we have that discussion, so check the archives from that page at the appropriate time. Billinghurst (talk) 22:47, 9 March 2011 (UTC)
- Hello 69. The deletion discussion was archived to Wikisource:Possible copyright violations/Archives/2006-07#Dada Manifesto (1918, Tristan Tzara); you can find the deletion discussion through the "What links here" link in the sidebar. The page was deleted because there is no information available on the translation's copyright status. The default assumption in such cases is that copyright was not waived. —Pathoschild 23:00:54, 10 March 2011 (UTC)
Updating the common.js file
Gday. Just saw the following in Mediawiki:Common.js
/*************
*** Execute JS file in MediaWiki namespace with &usejs parameter on any page
*** by [[m:user:Pathoschild]] <http://meta.wikimedia.org/wiki/User:Pathoschild/Scripts/Usejs>
*************/
document.write('<script type="text/javascript" src="'
+ 'http://meta.wikimedia.org/w/index.php?title=User:Pathoschild/Scripts/Usejs.js'
+ '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
From what I have seen written we should be looking to update these, where possible, to ResourceLoader scripting, and no more document.write. Are you able to modernise those bits, or is this part of a different overarching plan? Thanks. — billinghurst sDrewth 00:49, 11 April 2011 (UTC)
- Mr Sticky nose again. Just wondered whether you had considered sticking some of these scripts at mw:Snippets. Looking at our common.js/css files they seem heavily loaded with archaic components based on old ways and may need a refresh. — billinghurst sDrewth 01:12, 11 April 2011 (UTC)
- I recently started a slow migration of my tools in use to all the new stuff. For example, you might be interested in the new pre-release version of TemplateScript, a complete rewrite. It now uses all the new JavaScript, is compatible with all skins, addresses a slew of problems with the old design, and has new script support. The regex menu framework is no longer in development; some of its useful functionality is (or will be) merged into TemplateScript, which supports both templates and scripts.
- As for this case — usejs is ancient, and I don't think anyone is actually using it. I have no plans to update the code. I think you can simply remove it from common.js. —Pathoschild 05:44:36, 11 April 2011 (UTC)
sul problem
I'm not sure if you are the right person to ask, but my sul has not worked at en.wiktionary for some time now. I've not encountered any other problem with it, it works fine at any other sister-site I visit. CYGNIS INSIGNIS 13:05, 8 May 2011 (UTC)
- Strange; it's properly unified in the database. Do you get logged in automatically on other Wiktionaries like frwiktionary? Has this only happened since the last time you logged in globally, or does it happen consistently? If you haven't already, try logging out globally and logging back in. You can also try asking in the #wikimedia-tech channel on freenode. If all else fails, unmerging and remerging enwiktionary might fix the problem. —Pathoschild 18:33:56, 08 May 2011 (UTC)
- Thanks, and an apology. I have managed to get one browser to behave by allowing a cookie, it seems I accidentally denied accepting them at one stage. CYGNIS INSIGNIS 09:54, 9 May 2011 (UTC)
Blocking
I demanding a test block in 387 seconds. 1.55.104.176 09:14, 5 August 2011 (UTC)
Old proxy blocks
Gday, if you have a peek at https://en.wikisource.org/w/index.php?title=Special:BlockList&offset=20070516232102 you will see some really old proxy blocks. Do these need to remain? I would have thought that there were better and active means by global users to manage these. If they are appropriate to stay, okay. — billinghurst sDrewth 11:40, 30 June 2012 (UTC)
- Hi Billinghurst. It should be pretty safe to unblock them; proxies are now blocked globally by stewards. —Pathoschild 13:27:59, 30 June 2012 (UTC)
Wikisource User Group
Wikisource, the free digital library is moving towards better implementation of book management, proofreading and uploading. All language communities are very important in Wikisource. We would like to propose a Wikisource User Group, which would be a loose, volunteer organization to facilitate outreach and foster technical development, join if you feel like helping out. This would also give a better way to share and improve the tools used in the local Wikisources. You are invited to join the mailing list 'wikisource-l' (English), the IRC channel #wikisource, the facebook page or the Wikisource twitter. As a part of the Google Summer of Code 2013, there are four projects related to Wikisource. To get the best results out of these projects, we would like your comments about them. The projects are listed at Wikisource across projects. You can find the midpoint report for developmental work done during the IEG on Wikisource here.
Global message delivery, 23:22, 24 July 2013 (UTC)
2000 BCE to 1000 BCE birth and death dates categories
I nominated these categories for deletion at WS:DEL. Join the discussion if you wish. ResScholar (talk) 21:37, 25 September 2013 (UTC)
- Thanks for letting me know; I have no objection. —Pathoschild 19:01:08, 28 September 2013 (UTC)
Retired?
This edit seems to imply you are retiring as an admim on WS. I hope is all is well in your life, and that you will still be around. Jeepday (talk) 10:56, 17 April 2014 (UTC)
- Hi Jeepday. Thanks for your concern. All is well, but I'm retiring as admin since I'm no longer active on-wiki. I'll still lurk as a regular user. :) —Pathoschild 02:51, 18 April 2014 (UTC)
- Hi, Pathoschild. I've never worked with you but I've seen a lot of your work throughout the WMF sites. So this is just to say thank-you for that, and wish you all the best in the future. :-) Best regards,—Clockery Fairfeld (ƒ=ma) 03:17, 18 April 2014 (UTC)
- Hey bloke, enjoy your retirement, I wondered when it was coming as you have trimmed and trimmed. Remember that I am still around if you need more "fam res" done. Enjoy your time with Shanel. — billinghurst sDrewth 12:51, 18 April 2014 (UTC)
- Hi, Pathoschild. I've never worked with you but I've seen a lot of your work throughout the WMF sites. So this is just to say thank-you for that, and wish you all the best in the future. :-) Best regards,—Clockery Fairfeld (ƒ=ma) 03:17, 18 April 2014 (UTC)
TemplateScript
Beeswaxcandle's scripts
Hi, George tells me that I should ask you to do something with my common.js in relation to regex. I just copied scripts from Hesperian's a couple of years back because they seemed useful. I must also thank you for the template preload gadget. It's been invaluable over the years. Beeswaxcandle (talk) 06:03, 25 August 2014 (UTC)
- Hi Beeswaxcandle. Thanks for the feedback. :) You have a custom version of the regex menu framework with added keyboard shortcuts; if I update you to TemplateScript now, you'll lose those. I'll look into adding keyboard shortcuts to TemplateScript first so you don't lose anything. In the meantime, do you use all of your sidebar scripts? The scripts I see are header [z], clean up [x], makeref, footer [f], small-caps [c], upper [u], reload, and pagename. —Pathoschild 00:38, 26 August 2014 (UTC)
- I added keyboard shortcuts to TemplateScript and migrated your common.js page to TemplateScript. Let me know if you notice any issues. —Pathoschild 03:22, 26 August 2014 (UTC)
- Thanks. Behaviour seems to be as expected. In terms of who else is using Hesperian scripts, the editors that I have pointed in that direct are: Susanarb, William Maury Morris II, & Jfhutson. Maury's was copied from mine, whereas Susan's and Jfhutson's were fresh copies from Hesperian's at the time. Beeswaxcandle (talk) 09:12, 26 August 2014 (UTC)
TemplateScript library
(continued from previous section.)
That will help with "copy cat-ers" but User:Hesperian's implementation seem to be the "route" all others seem to stem from. And fwiw... User:William Maury Morris II's seems to be the most "broken" of late. -- George Orwell III (talk) 04:01, 26 August 2014 (UTC)
- How many users have Hesperian scripts? It might be worth turning the generic ones into gadgets, or creating a library of scripts so you just importScriptURI them instead. —Pathoschild 04:41, 26 August 2014 (UTC)
- Not sure how many but most of the ones I come across (i.e. something stopped working thanks to some js module or syntax being recently deprecated in the core) all seem to cite
himhis tools in the comment/hidden text.Of course it would be worth turning the repetitive ones into gadgets, but deciding which ones specifically takes the 'ol 'proposal, discussion, consensus, etc.' route - ~60 days in short - to truthfully cover the core "regular contributors". We just don't have consistent enough traffic by those class of folks from week to week; its more like month to every other month. This also makes gadget oversight and newbie questions problematic to say the least.
IMHO... I say fix what you can now then make a proposal to gadgetize the more frequently appearing ones that can be fulfilled once everybody who "matters" eventually chimes in on them one way or another. -- George Orwell III (talk) 04:53, 26 August 2014 (UTC)
- Not sure how many but most of the ones I come across (i.e. something stopped working thanks to some js module or syntax being recently deprecated in the core) all seem to cite
- Thanks. Behaviour seems to be as expected. In terms of who else is using Hesperian scripts, the editors that I have pointed in that direct are: Susanarb, William Maury Morris II, & Jfhutson. Maury's was copied from mine, whereas Susan's and Jfhutson's were fresh copies from Hesperian's at the time. Beeswaxcandle (talk) 09:12, 26 August 2014 (UTC)
- May I add to Beeswaxcandle's note above: Clockery chains to Susanarb and thus will be similarly affected? AuFCL (talk) 10:17, 26 August 2014 (UTC)
- @George Orwell III: I see Wikisource:TemplateScript as a way to reduce this copy & pasting, without going through the long process of creating gadgets. TemplateScript is almost its own gadget framework anyway. —Pathoschild 00:15, 27 August 2014 (UTC)
- Hesperian and I set up the criteria for the first set of text replacements, and we probably shared our earlier updates, though as time progressed we didn't pick up each other's successive updates (comfort? didn't notice? ...). With regard to extracting a gadgetised form, I would suggest that we just pick one/two/three and run with it/them. People can work out whether they want it or not(?), and we can pick up those less-regulars as they appear. We just need to drop them a note to say come by WS:AN if they need help. With regard to a pluggable importScriptURI, having something that can easily be set per book would be useful, and have something for a generic PotM which allows someone setting up each work to plug and pray that it updates to whichever the next PotM may be. — billinghurst sDrewth 04:06, 27 August 2014 (UTC)
- I imagine only generic tools would be listed on Wikisource:TemplateScript, but we certainly could have PotM or work-specific scripts too. —Pathoschild 04:15, 27 August 2014 (UTC)
- Template:PotM already has a parameter POTMindex ready to align, and apart from when we flop into overflow (as now), the other variations of that template all allow the pull of that parameter. Other index /page files where djvu/pdf probably can slip straight into a variant. I already have some hacks for some of my forever works with a little complexity, but it is maybe the ability to maybe automagically align a work with a template, and there maybe it is something like Index:ThisWork.djvu can have a Index:ThisWork.djvu/TemplateScript which we could link from the index page, and use preload and/or editnotice to add a script framework. <shrug> That is where my lazy brain went and a link to some help pages. — billinghurst sDrewth 05:09, 27 August 2014 (UTC)
- Wikisource:TemplateScript is experimentally live, so we should discuss specific cases on Wikisource talk:TemplateScript or Wikisource:Scriptorium. —Pathoschild 15:09, 02 September 2014 (UTC)
Downtime
It was all working 24 hours ago, but is no longer. Beeswaxcandle (talk) 09:49, 28 August 2014 (UTC)
- The Tool Labs webservice serving the script failed; it should be working now, but I'll need to look more into the cause. —Pathoschild 17:09, 28 August 2014 (UTC)
- That might be the same issue I had when I used the Labs version (which motivated me to copy the script to Wikibooks and load it from there). Helder 18:59, 28 August 2014 (UTC)
- I don't think so. This downtime was caused by the server refusing connections due to a connection limit. That's likely an issue with Tool Labs configuration; once resolved it shouldn't happen again. —Pathoschild 19:05, 28 August 2014 (UTC)
Moondyne's scripts
I came here to ask for your help with my scripts also but from reading above I sense a site-wide user-friendly solution may be in the wind. If not, your assistance here would be very much appreciated. If so, even better and thanks in anticipation. Regards, Moondyne (talk) 14:03, 28 August 2014 (UTC)
- Please, what must I do to get my cleanup script working? Moondyne (talk) 07:57, 1 September 2014 (UTC)
- You use some of the same scripts as above, so I'll implement shared scripts first to avoid duplication. I've started making the required changes, and I'll migrate you to it as soon as it's ready. —Pathoschild 16:34, 01 September 2014 (UTC)
- @Moondyne: I migrated you to the new shared scripts. I gave you the full set of page tools; let me know if you'd prefer to only have the scripts you had, or if you notice any problems or have questions. —Pathoschild 02:15, 02 September 2014 (UTC)
- I see no change. Is there something I need to turn on in prefs? Moondyne (talk) 04:25, 2 September 2014 (UTC)
- @Moondyne: I migrated you to the new shared scripts. I gave you the full set of page tools; let me know if you'd prefer to only have the scripts you had, or if you notice any problems or have questions. —Pathoschild 02:15, 02 September 2014 (UTC)
- You may need to bypass your browser cache, if you haven't already. —Pathoschild 04:43, 02 September 2014 (UTC)
- Fwiw... Moondyne might be referring just to the missing 'Classic' toolbar in the Page: namespace issue which has been known to interfere (load order?) with one thing or another regardless of its relation to the actual toolbar(s). I think he's moved to WikiEditor as a result of the bug in the interim however and that might be why he's expecting to see some sort of "change" even after you updated his RegExp stuff. In short, that lack of change could still be due to the fact the reversion patch (see Bugzilla:69447, to be applied here on WS in Sept. 2nd's 1.24wmf19 build) simply hasn't been applied yet is all. -- George Orwell III (talk) 05:15, 2 September 2014 (UTC)
- Browser cache is cleared. What I’m seeing. Moondyne (talk) 05:28, 2 September 2014 (UTC)
- Pathoschild, I am still having no joy with my sidebar scripts. Scripts display but aren't working. Conflicting preferences are disabled as far as I can see [2] [3]. George has edited my User:Moondyne/common.js but was unable to crack it. I have cleared cache and changed browsers. Moondyne (talk) 13:28, 2 September 2014 (UTC)
- @Moondyne: You can see the tools now, which means TemplateScript itself is working. I fixed a few issues with the page tools; please clear your browser cache and try again. —Pathoschild 14:15, 02 September 2014 (UTC)
- Woohoo! We have lift off. Moondyne (talk) 14:34, 2 September 2014 (UTC)
- Great! You now have an updated cleanup script from Beeswaxcandle's scripts, so it's not the same version you had before. Let me know if there are any issues or missing fixes, and I'll update the shared version. —Pathoschild 14:46, 02 September 2014 (UTC)
I'm not fussed about that. Thanks for your help. Is it possible to add the rh script into the sidebar or the editing toolbar? Moondyne (talk) 08:25, 3 September 2014 (UTC)
- What is the rh script? —Pathoschild 01:13, 04 September 2014 (UTC)
// Running header toolbar button
importScript('User:Inductiveload/Running header.js');
- the rh button on my old edit toolbar inserted a running header template in the page: header with an incremented page number. Worked well until a few weeks ago. Moondyne (talk) 01:35, 4 September 2014 (UTC)
- I think your sidebar script called Add header does that. —Pathoschild 01:40, 04 September 2014 (UTC)
- That doesn't work quite as well. The old one copied the middle parameter from 2 pages previously as well as incrementing the page number, so even when you had different headers on verso and recto, it was all done. The one thing it didn't do, which Add header does, is remove the first line in the body. Moondyne (talk) 02:05, 4 September 2014 (UTC)
- it looks like that was User:Inductiveload/Running header.js, which Beeswaxcandle disabled when he added the enhanced toolbar buttons. I'd suggest asking them about re-enabling it or adding it to the new TemplateScript library. —Pathoschild 02:09, 04 September 2014 (UTC)
Scripts have stopped running
Hi, they were all working fine on Friday evening (NZDT—UTC +13), but weren't at some point on Saturday. By "stopped running" I mean that they aren't available in the side-bar when editing. I've refreshed, cleared cache, and even re-started the computer, all to no avail. Is Tool-labs having a problem? Or is there something else I should try? Beeswaxcandle (talk) 04:51, 29 March 2015 (UTC)
- Hmm, either you're really on to it, or it's just resolved itself. I proofread two pages after writing the above, then moved onto a third when the scripts appeared. Beeswaxcandle (talk) 05:02, 29 March 2015 (UTC)
- Hi Beeswaxcandle. Yep, there was a problem with the way the scripts were redirected to the new static server. I fixed that, and updated your common.js to the latest version of the script for good measure. The new version is better cached and is on a faster server, so you should be less affected by issues on Tool Labs. —Pathoschild 05:12, 29 March 2015 (UTC)
my common.js, I still miss basic concepts
My understanding of JS is clearly still missing a basic concept as I cannot get the basics of text replacement working in my js. If you have a chance, I would appreciate if you could fix a couple and I can follow on from your lead. Thanks. — billinghurst sDrewth 05:15, 20 July 2015 (UTC)
- Hi billinghurst. The main issues I found were using
context
as a global (instead of an argument passed to the function), and trying to use$target
on jQuery objects (it's acontext
property). You can also paste your code into jshint to detect some common issues. I fixed the issues I found, but I haven't tested your scripts. Let me know if anything is still broken. —Pathoschild 00:02, 22 July 2015 (UTC)
The old regex is still referred to there. Did you wish to update it? — billinghurst sDrewth 23:19, 16 August 2015 (UTC)
- Sure. I responded in the Scriptorium discussion. —Pathoschild 00:57, 17 August 2015 (UTC)
Updated common.js breaks the "Clean up" function
Hi Pathoschild, thanks for updating my common.js but I've found the "clean up" script I use no longer works. I use it a lot to remove extra line feed/carriage from text, which solve many italics issues where the italics spreads across multiple lines. DivermanAU (talk) 20:47, 12 September 2015 (UTC)
- Hi DivermanAU. How does the script fail? Do you see the TemplateScript sidebar with a clean up option? Does clicking on clean up do anything?
- Please also try the following:
- Clear your browser cache to make sure you have the latest version.
- While editing a page (and clicking clean up if you see it), are there any errors in the JavaScript console? If there are, please paste them here.
- While editing a page, run the following command in the JavaScript console. This will add a big block of text to the console, beginning with
<source
and ending with</source>
. Send me that text (you can paste it here or email me, whichever you prefer).mw.loader.load('https://meta.wikimedia.org/w/index.php?title=User:Pathoschild/Scripts/debug.js&action=raw&ctype=text/javascript')
- —Pathoschild 14:13, 13 September 2015 (UTC)
- I got my clean-up and line removal working fine — (well, for most parts, I just need to fix my matching bits for DNB stuff) — billinghurst sDrewth 00:45, 14 September 2015 (UTC)
A user's scripts need help
Hi, User:William Maury Morris II/common.js needs help. Maury tells me that the keyboard shortcut Alt-Ctrl-X has stopped invoking the cleanup script. When I look at the page I see that it's become a mishmash of various versions of my common.js and monobook.js along with bits of Hesperian's and Billinghurst's. Pretty much the only script he uses is the cleanup, but he will need to keep the extra buttons. Are you able to help? Beeswaxcandle (talk) 02:15, 26 September 2015 (UTC)
- Hi Beeswaxcandle. I removed the unused scripts and migrated to the latest version of TemplateScript. William Maury Morris II was using a much older version called regex menu framework (which is no longer maintained), so he should notice a lot of improvements. Notably keyboard shortcuts are built-in with TemplateScript, so you no longer need custom scripts to add them. A few of the big changes:
regex menu framework TemplateScript regex editor ✓ ✓ improved regex editor with syntax highlighting which can save patterns for later use compatibility unknown ✓ compatible with all skins and modern browsers custom scripts limited ✓ much better framework for writing scripts supported views edit ✓ add templates and scripts for any view (edit, block, protect, etc) keyboard shortcuts ✘ ✓ add keyboard shortcuts for your templates and scripts
- Let me know if anything breaks or there's a script missing. :) —Pathoschild 13:38, 26 September 2015 (UTC)
Cleanup not working properly in TemplateScript
It removes a few random hard returns only. Any ideas? Moondyne (talk) 13:10, 26 October 2015 (UTC)
- Hi Moondyne. It seems to be working for me. Could you link me to an example page where it's not doing what you expected (and specify what it's not doing)? —Pathoschild 23:01, 26 October 2015 (UTC)
- [4] shows what it does when I press Clean up OCR. Make reference seems to do nothing. The other page tools all seem to work correctly. Moondyne (talk) 01:55, 27 October 2015 (UTC)
- The scripts seem to work as designed:
- Clean up OCR removes newlines if the line ends with a hyphen, is enclosed in
<poem>
, and a few other specific cases. There doesn't seem to be any intention in the script to remove newlines otherwise. - Make references is pretty specialised, but it seems to be working: add
<ref></ref>
(with nothing between the tags), highlight some random bit of text, and click 'Make references' to move the selected text into the<ref></ref>
tags.
- Clean up OCR removes newlines if the line ends with a hyphen, is enclosed in
- Did the scripts work differently before? —Pathoschild 03:16, 27 October 2015 (UTC)
- The scripts seem to work as designed:
- 'Clean up OCR' was working differently up until a few days ago. It previously removed all single line breaks, not just ones ending in a hyphen. It stopped working before I did any changes to common.js. I misunderstood how 'Make references' was meant to be used; that is now clarified. Moondyne (talk) 03:52, 27 October 2015 (UTC)
- I fixed an issue in the cleanup script that I think caused the change. Does it work for you now? (You may need to clear your cache.) —Pathoschild 13:21, 27 October 2015 (UTC)
- Fixed; thanks muchly. Moondyne (talk) 14:16, 27 October 2015 (UTC)
Minor issues with TemplateScript's underlying html syntax
First, thanks for taking the time to actually re-visit and improve upon this popular feature added well in the past; most folks just contribute and then disappear -- leaving their "tool" subject to being crippled by subsequent changes to "the code" later on.
Second, everything seems to work as advertised here but I noticed that the labels (the text wrapped in the H3 tag) revert to Tools when applied at the same time with the Sidebar Flat-list gadget enabled. I'm guessing this happens because of the id= duplication with the existing p-tb portlet. In other terms, your script is producing this....
<div class="portal" id="p-templatescript-0" role="navigation" aria-labelledby="p-tb-label">
<h3 id="p-tb-label">TemplateScript</h3>
<div class="body">
<ul>
<li id="ts-link-0" style="display: list-item;">
<a href="#">Regex editor</a>
</li>
</ul>
</div>
</div>
... when it should be generating the following instead...
<div class="portal" id="p-templatescript-0" role="navigation" aria-labelledby="p-templatescript-0-label">
<h3 id="p-templatescript-0-label">TemplateScript</h3>
<div class="body">
<ul>
<li id="ts-link-0" style="display: list-item;">
<a href="#">Regex editor</a>
</li>
</ul>
</div>
</div>
Note the difference in the overall DIV container's id=
attribute's value to it's aria-labelledby=
attribute's value and then to the child H3's id=
attribute's value. The same thing happens for a third "duplicate" also labeled Tools in the Page: namespace's Page Tools menu (plus no ⛭ interlink to the Special: page).
I'm hoping that if you correct those parameters to generate the inherent values so they mirror the rest of the side-bar "syntax" properly, this issue while the Sidebar Flat-list gadget is enabled along with your script will resolve itself easily enough. Thanks for your attention in advance. -- George Orwell III (talk) 23:57, 26 October 2015 (UTC)
- Hi George Orwell III. Thanks for the feedback! I corrected the ARIA attributes; let me know if that fixes the issue with the Sidebar Flat-list gadget. —Pathoschild 00:24, 27 October 2015 (UTC)
- Pathoschild: I do see the correction and now pretty much mirrors the example I gave above without the Sidebar Flat-list enabled. Same story as before however with the FS gadget enabled in spite of the fact the ARIA for the DIV container is now correct there too. So its probably something to do with the MediaWiki:Gadget-FlatSidebar.js itself; specifically the part where the "normal" H3 is 'replaced' with another DIV (most likely?).
Maybe the first thing we should do is make sure you can replicate the issue I'm seeing with the Gadget enabled before anything else. If so, maybe you can take a look at that script and work your magic on it? Otherwise I'm not sure what to do -- its really more a cosmetic thing than a functional issue anyway. -- George Orwell III (talk) 01:03, 27 October 2015 (UTC)
- Pathoschild: I do see the correction and now pretty much mirrors the example I gave above without the Sidebar Flat-list enabled. Same story as before however with the FS gadget enabled in spite of the fact the ARIA for the DIV container is now correct there too. So its probably something to do with the MediaWiki:Gadget-FlatSidebar.js itself; specifically the part where the "normal" H3 is 'replaced' with another DIV (most likely?).
- I think that's the issue: TemplateScript can't find the portlet header because the gadget replaced it with a
<div>
. You can fix compatibility by changing the gadget to use a header (anything from<h1>
through<h5>
), oder copy the header's ID to the<div>
and I'll change TemplateScript to check for the ID. —Pathoschild 01:46, 27 October 2015 (UTC)
- I think that's the issue: TemplateScript can't find the portlet header because the gadget replaced it with a
- Well can you take a look at the Gadget and tell me how to copy the H3's id= to the DIV replacement "string"? The whole point in the gadget is to break away from the use of Headings for the collapsible lists so the first option is really not a feasible one in this case. -- George Orwell III (talk) 02:05, 27 October 2015 (UTC)
- Pathoschild: I just realized the probable reason your headings are not being converted like any other add'l portlets are -- even when under the gadget applied -- is because you seem to "build" your portlets by cloning the common toolbox (#p-tb) portlet and then go about altering attribute values of those clones. That's why even though the DIV replacement of H3 by the gadget is successful, its at a point in the order where the H3's id- is still p-tb and the label (text) is still Tools from the cloning.
And fwiw... I can't "pin" (force open) the drop down menus for your portlet additions by clicking on the arrowhead under the gadget either though the "hover" functionality does drop & close just like the other portlet menus do. -- George Orwell III (talk) 02:48, 27 October 2015 (UTC)
- Pathoschild: I just realized the probable reason your headings are not being converted like any other add'l portlets are -- even when under the gadget applied -- is because you seem to "build" your portlets by cloning the common toolbox (#p-tb) portlet and then go about altering attribute values of those clones. That's why even though the DIV replacement of H3 by the gadget is successful, its at a point in the order where the H3's id- is still p-tb and the label (text) is still Tools from the cloning.
- Yep, TemplateScript maintains cross-skin compatibility by cloning the toolbox (which always exists) and modifying the content and attributes for its purpose. It modifies the IDs before adding to the DOM, so as long as it can find the header it shouldn't conflict with the gadget. With regards to pinning, is that added by the same gadget? —Pathoschild 03:01, 27 October 2015 (UTC)
- Yes, the pinning is done by the same gadget in question and is based on the same premise as Vector's Mehr tab's menuForceShow has.
Again so how do I copy the existing H3 id at the point in the gadget when its replaced with a DIV and not afterwards. Any other "added" portlet behaves like the rest under the gadget - but they all seem to built from 'scratch' rather than cloned (I don't care if its cloned in your case or not & like you said - it shouldn't matter). But since the AriaLabelledBy attribute's Value in the parent DIV of either the standard H3 child or the post-gadget DIV replacement is correct after your correction earlier today, there must be some way for the gadget to also have the child DIV have that same value for its ID attribute; I'm just not skilled enough to know how to accomplish that in the gadget is all. Please help if you can. -- George Orwell III (talk) 03:12, 27 October 2015 (UTC)
- Yes, the pinning is done by the same gadget in question and is based on the same premise as Vector's Mehr tab's menuForceShow has.
- I adjusted the gadget to keep the header ID, and changed TemplateScript to match. Does that fix the original issue? —Pathoschild 03:25, 27 October 2015 (UTC)
- Yup, After I re-added the class & value your edit accidentally removed, the heading issue is resolved -- they are no longer being duplicated and the underlying html tag, attribute and respective values all mirror the other portlets (custom add-ins or regular defaults regardless). Thank You!!
Still no "pinning" for your drop-downs and no ⛭ interlink to the Special: page for the Page Tools however. Personally, I can live with the way things are as it stands now but you know how it goes -- eventually somebody will get a bug up their ass about it. -- George Orwell III (talk) 03:47, 27 October 2015 (UTC)
- Yup, After I re-added the class & value your edit accidentally removed, the heading issue is resolved -- they are no longer being duplicated and the underlying html tag, attribute and respective values all mirror the other portlets (custom add-ins or regular defaults regardless). Thank You!!
Keyboard shortcuts have disappeared with latest version of my common.js
Hi, the new Page Tools box looks better than it did, thanks for that. However, because I work on a laptop without a mouse I prefer keyboard shortcuts for as many things as possible. Is there a straightforward way to get the keyboard shortcuts back? Also, there's a character (with a link behind it) in the heading for the box that is displaying as a character box rather than the actual character. Is there another option for that character? Cheers, Beeswaxcandle (talk) 07:34, 3 November 2015 (UTC)
- Sorry about that! The library doesn't set any shortcuts; I'll extend TemplateScript this evening to let users add custom shortcuts for imported scripts. I'll let you know when your shortcuts are back; in the meantime feel free to revert if the missing shortcuts are very inconvenient. With regards to the broken character, I'll probably replace it with an image to address Unicode support issues. —Pathoschild 17:42, 03 November 2015 (UTC)
- @Beeswaxcandle: you should have your shortcuts back now. (I'll fix the character box issue separately.) Let me know if there's anything missing. —Pathoschild 00:19, 04 November 2015 (UTC)
- Seems to be fine now. Thanks heaps, Beeswaxcandle (talk) 01:22, 4 November 2015 (UTC)
Hey. User:Pathoschild/standardise.js gets categorized into Category:$1$2$3 (mainly because Mediawiki is being dumb). Any chance you could de-fang that? I imagine the simple approach is to prefix it with a colon in the existing substitution, and then just add another substitution that removes the colon from the string. Anything that prevents the literal string [[Category:…]]
from appearing in the page. --Xover (talk) 11:29, 29 August 2019 (UTC)
- Fixed! —Pathoschild 01:22, 30 August 2019 (UTC)
- Thanks! --Xover (talk) 07:30, 30 August 2019 (UTC)
parameters based on Title
Hi mate. Hope that you are well. With templatescript in common.js, I obviously don't grok how to set certain scripts to show based on a url/title. Things BDMRset and DNBset hard variables set at the top, then these variables are called in the scripts (I believe as you showed me)
var isDNB00 = mw.config.get('wgTitle').match('Dictionary of National');
var isBDMR = mw.config.get('wgTitle').match('Biographical Dictionary of Modern Rationalists');
},
enabled: isDNB00
},
however, they are showing up no matter what page I am on. Could you please help this nonce fix things up. Thanks if you can. — billinghurst sDrewth 03:22, 19 April 2021 (UTC)
- Hi! The problem is that
match('…')
returns null if it doesn't match, andenabled: null
is the same as omitting it. You can explicitly convert those variables to boolean with!!
to fix that: var isPageNS = mw.config.get('wgNamespaceNumber') == 104; var isIndianBio = isPageNS && !!mw.config.get('wgTitle').match('The Indian Biographical Dictionary.djvu/'); var isIrishBio = !!mw.config.get('wgTitle').match('A Compendium of Irish Biography'); var isBiography = !!mw.config.get('wgTitle').match(/[\w ]+Biography/); var isDNB00 = !!mw.config.get('wgTitle').match('Dictionary_of_National'); var isDictionary = isPageNS && mw.config.get('Dictionary of National'); var isBDMR = !!mw.config.get('wgTitle').match('Biographical Dictionary of Modern Rationalists');
- —Pathoschild 19:51, 19 April 2021 (UTC)
- Thanks, magic. These used to work that way, so failed during one of the upgrades. — billinghurst sDrewth 00:46, 20 April 2021 (UTC)