From Ring of Brodgar

MvGulik Personal work page. [+]. Last cleared: 07:07, 9 November 2017 (EST). (prev-rev)

General RoB issues log:


... Initiating: Outdated entities disposal job (and see what changes) -- 18:35, 15 July 2018 (EDT)

... TODO: recheck Template:Sm-sep-aa workings (Template:Str mca and Template:Str spsc seems to work properly .. later)
... TODO: local property_tables scanning code needs a fixup. (none page-properties show up as wiki links ... later)

- Weird wiki spacing behavior:

	- Following (example) pages show different spacing (page text start after infobox end)
		- Legacy:Stone Working
		- Legacy:Hazelnut Tree
	Although both pages use different infobox templates, both infobox templates are using the same relevant code (stuff outside the infobox table code).
	Both pages start with a section header, although the same can be observed on pages that start with normal text.
	... Something to dig into for later. (''probably related to some deeper down used template'')

- Odd problem/Ghost(?) pages:

		- Old case.
		- Still injecting some unintended property data (recheck ... later)
		- (recheck ... later)
		-- Resolution: leave as is for now, investigation on hold.

		- new data (after RoB update)
		-- Property:Hurtpertotalfep - as type:number - showing "Running Rabbit Sausage(backup)"="0" => none existing page. (delete ... none issue, for later)
		-- Property:Fepperhunger - as type:number - showing "Running Rabbit Sausage(backup)"="0.1" => none existing page. (delete ... none issue, for later)
		-- "Running Rabbit Sausage(backup)" also showing up (as deleted page) in "requires" property list (SMW-SearchPage)

		Other data:
			- A "Legacy:Metal Meat Grinder" case is precent in the "Requires" property list. ++ (not spotted after update ... )
			-- Reported to be set by page "Running Rabbit Sausage(backup)" ... (which is not possible on many (normal) levels)
			-- The source page "(Legacy:)Running Rabbit Sausage" has used "requires::Metal Meat Grinder". (current its "Legacy:Metal Meat Grinder")
				- Check legmetaobj template (although there is no SMW annotation for pages in the Legacy namespace ++ now enabled ...)
				- ... find more info on mediawiki internal page-history/action storing.
				- "Legacy:Running Rabbit Sausage": page purge & null-edit ... no effect or other change.
			Also in "Requires" list:
				"Legacy:Sausage Making" <= "Running Rabbit Sausage(backup)" ++ (not spotted after update ... )
				"Legacy:Water" <= "Legacy:Honey Bun" ++ (not spotted after update ... )
			Old talk about Running_Rabbit_Sausage -

		- Old case.
		- ++ still there after update (but now end up in a bad name page)
		- Reason: Unknown so far.
		-- Xsize of type Number (1,101 uses) ... one more than Ysize, might be a clue to the source.
		-- Ysize of type Number (1,100 uses)
		++ changed, now both at (1,717 uses)
		-- Resolution: leave as is for now, investigation on hold.
		- Moved the related page/history (but forgot to purge it first)
		-- leave as is for now, to see if the system/cache changes in time.
		-- old outdated cache could be part of the problem ... time will tell, I hope.

- Image-files:

	- No clear/active/single standard/rules for the separation of Hafen and Legacy image-files.
		- Related to auto-image-links for game related subject pages.
		- Legacy image-files that get updated with there Hafen counterpart, also effect the image on the Legacy page.
		-- This makes keeping up the Legacy data/pages a bit questionable in the long run.
		At first, before the Legacy name-space was added, the default was to name them with a leading "Hafen_*" part.
		This made sense up to the point the Legacy name-space was added. (not sure about trying to re-implement this at this point)
		Unfortunately the 'outdated' scheme for moving Legacy pages was not supplemented with a similar plan for game-related images.
		Leading to a bit of a mess when it comes to the Hafen and Legacy images,
		and making it somewhat of a big and tricky job to straiten thing out again.
		Options: (So far. Needs some more thinking/experimenting, talking, and a general agreement before implementing)
		- (General):
			+ Template: Default Legacy images to "Legacy_*" (while, for the moment, falling back to the normal image name)
			-- Can probably be done already, no matter which option is picked/used.
		- 1(Most simple):
			- Copy last Legacy image(s) to new "Legacy_*" named image-file(s). (history it left behind)
			-- (Not using "Legacy:*" as leading name-part, as that is name-space ambiguous)
		- 2(Bit less simple):
			- Move the image-file to "Legacy_*", and copy back the last image (even if its a Legacy-related image[1]).
			| (history is moved to "Legacy_*" level)
			| [1]: Not sure yet about using redirects here, ... probably best not to.
		- 3(Not so simple, and not devoid of triggering potential problems):
			- Separate/split the images/image_history (when relevant) into its Hafen/current and Legacy part.
			| (although this seem possible, it also needs some additional investigation and experimenting on my part)
		- ?:other:
		-- Personally I think this image shuffling is best done trough API calls ... if/when available.
		++ WIP (''...I better start working on that API part...'')

- Old 'SBtt1...' properties (2 August 2018 (EDT)
	Some 'SBtt1...' property seemed to pop-up out of nowhere. (at User:MvGulik/property_tables page)
	- Not sure if it was already listed at the MW property pages, but not showing yet at the property_tables page.
	- There seems to be no active/current source page/revisions using SBtt1. (seems related to some old record-data experiment of mine.)
	- Investigate (low priority)


- Properties and Redirects ... do not mix nicely.
	- if a property value is used that has the same name as a redirect page => property value-name gets change to redirected page name.
	- resulting in, at least ambiguous name-data displayed at the property page, at most it injects unwanted data.

- Property page listing. (SMW 2.5.6) (MW 1.31.0) (Jan 2019)
	The last item in the list on a property page is subject to not being shown. (just not shown, working properly otherwise)
		- test case: property Lift, count 190. (did show "Wooden Plow") (did Not show "Wooden Plow")
		- seems general issue for all general property pages.

API/bot stuff

General targets/progress:

... Workout automated splitting of mixed Legacy-Hafen image histories.
... Remove image "hafen-" prefix (+ rename/move images that are in the way (Done, ... for now)

History modding

  • MediaWiki History Merge feature only acts on page history, and not on image/file-history part in File-pages. Bummer, but expected.
  • Restoring a newer image revision (with GUI) on a page that already has some older image active/current, results in a image/date-order mismatch.


  • Finish splitting Hafen and Legacy images: (main target at the moment --.MvGulik. 02:53, 4 March 2019 (EST))
    • (check for hafen- name collisions)
      • (ditch leading hafen- image name part)
        • (ditch Hafen- variation from auto-image code)
          • (see which related categories can be ditched)
(Finally ditched my original plan, and replaced it with way simpler plan B ... )

  • Find, check and separate the multiple-image moving/renaming code.
    • Current target: Global tree-map/terrain image renaming.
      • (would/should update all links in linked-by pages with a single edit(all images in given session) per linked-by page)

  • Check general used PNG compression level on game-resource images. (auto upload)
    • ...

  • (SMW) Recalled property lists can have an additional second space in between entries.
    • Makes detecting particular property changes fail to compare properly.

  • Template:Str spsc:
    • Move remarks to doc page.
    • See about using Trim here.

RoB Bot Stuff (2)

Bot Tags
Some RoB pages have <!--bot:<IDCODE>:begin--><!--Type:<TYPE-STRING>-->...<content>...<!--bot:<IDCODE>:end--> html-remark on them.
These remarks means the enclosed section/text is specifically subject to being changed by a bot-program/script.
<!--bot:<IDCODE>:begin--> and <!--bot:<IDCODE>:end--> effectively being the bot-section start and end markers.
<IDCODE> being there to make sure the right section is targeted. (in case there might be more than one bot-section on a given page)
<TYPE-STRING>(Type:): Giving information about the bot processing. Can contain:
"WriteOnly": In which case the whole bot-section content is ignored and ditched when being updated. (Editing is futile, and will NOT be assimilated. ;-) )
"Read/Write": User changes are maintained when being update.

+ For all bot-section parts (except of course the enclosed content) the following note applies: Don't change them without a good reason.

(nts: "ReadOnly" ... not sure yet. Relates to data pulling and not editing. Have no real case yet where this really matters. (would technically only matter in case of scanning-code insufficiency)
Well, that's not completely true. Enclosing remarks in brackets on terrain-page table, to easily detect and ditch them as none-data, is such a case. But that one is/should be a temporary one instead of a permanent one.
Current pages with a bot-section:
... (wip ... continued later)

Home-Coded Bot-Editing Tool
When RoB's global replace will not do, ... or is not needed.
  • Implemented default edits. (general page cleanup + uniformation (applied on top of targeted edit))
    • Leading and trailing page-blanks cleanup. (no known Wiki-issues so far)
    • Trailing line-spaces cleanup (no known Wiki-issues so far)
    • Add leading space to template parameter names. ("|Foo" => "| Foo") (issue: not limited to template section at the moment)
      • more after implementing separate template support code.*
    • Moving category assignments on page, below the initial infobox template. (issue: assumes there is an initial template-call ...)
      • ditches auto-set categories from page for: Specific=<names>, ...

*) This would include re-ordering the template parameters. I'm open to order/format suggestions (on talk).
Adding blank-lines, as visual separators, between related-parameter groups is an active consideration.
(Progress(1: The intended processing of Mediawiki pages turns out to be a more tricky than expected. Hope I have passed most speed-bumps at this point ... )
(Progress(2: Special RE-capturing of tables turned out to be a bit of a headage. But the intended page-splitting base-process now works as intended. ... )
(Progress(3: After some Regex Fine-tuning, code cleaning and extending wiki-targets the base-page-processing is basically done. Next: looking at infobox specific processing ... )
(Progress(4: First test run(trees) went ok. (phew) ... )

  • TODO's
    • Check & Fix global file-renaming script. (look into setup for reading wm-table specified file-renaming data (ie: source + target)
      • See if template processing is feasible. (minor/low priority)
    • Add grouped page-moving/renaming support (image, others) (includes updating of links-here pages)
    • ...

Forum links scanner/modifier. (todo)
  • Pull potential target pages by way of RoB-Replace. (http cases) (manual) ... (150+ "../forum/..")
    • Seen "../forum/*" cases: "<empty>"(is forum main-page), "viewtopic"(topic or post link), "viewforum"(forum section), "memberlist"(not supported. requires being logged in btw)
  • Scan HFL cases for missing title and/or date. (needs HFL administration category)
  • Title and date pulling from HnH forum.
  • ...

SMW Stuff

SMW New Properties processing

  • Newly to-be-set SMW properties only become useable (on the page in question) after saving the page.
    Completely trashing any related #ask or #show usability on those to-be-set properties in preview mode.
    • Investigate:
      • Is this really the norm.
      • SMW settings related(?), or other reasons.
      • Potential alternative MW extensions.

SMW #Show behaviour

test data
- Beach => Existing wiki-page.
- Beach => Existing entry in Category:Terrain. (case to be investigated ...)
- Beach => Property-field-name in property-page "terrain_fauna".
- #iferror :: MW error state not used by SMW stuff. Always returns as correct on #show.
Possible Syntax Rundown
  • Property mode: {{#show: <property-field-name> | ?<property-page-name> }}
    • Returns field-data.
    • Returns empty-string on invalid property-field-name or invalid property-page-name.
  • Wiki-Page mode: {{#show: <page-name> | ? }}
    • Returns name of found page. (PAGENAME text, FULLPAGENAME link, Follows Redirects)
    • ... interesting case. Potentially useful as alternative #ifexist. ... Nope. Gets triggered on deleted file-pages. (file-pages only)
  • Invalid: {{#show: <parm1> | }}
    • missing parm-2 content, no error, just empty string as result.
  • Invalid: {{#show: <parm1> }}
    • missing parm-2 part, no error, just empty string as result.
id code result success Remark
11 {{#show: Beach }} No <empty> (improper usage, missing second parameter)
12 {{#show: Beach | }} No <empty> (improper usage, missing second parameter content)
21 {{#show: Beach | ?foobarfoo }} No <empty> (none existing property page)
22 {{#show: Beach | ?Terrain }} No <empty> (none existing property field name)
23 {{#show: Beach | ?terrain_fauna }} Crab, Dryad, Grey Seal, Walrus, Sand Flea Yes "Crab, Dryad, ..." (existing property-field in existing property-page)
31 {{#show: Foobarfoo | ? }} No <empty> (none existing page)
32 {{#show: Beach | ? }} Beach Yes "Beach" (existing page)
33 {{#show: Category:Objects-Hafen | ? }} Objects Yes "(Category:)Objects"
(Follows redirects, Strips namespace (on text, not on link))
34 {{#show: Category:Objects-hafen | ? }} No <empty> (Case sensitive)
35 {{#show: File:Dead Bunny.png | ? }} File:Dead Bunny.png ??? <Red-File-Link> (Deleted File-case)
9- {{#show: ... | <Category> }}   --- ...