Property talk:Has location type

Allows value

The allowed value "Dragon Response Mission" is getting stored in the property Allows value, see the following smw inline query: Continent, Region, Zone, City, Lobby, Guild hall, Dungeon, Raid, Fractal, Instance, Activity, Dragon Response Mission, Strike Mission, Guild Puzzle, Conquest, Murderball, Stronghold, Team Deathmatch, Area, Point of Interest, Jumping puzzle, Landmark, Mini-dungeon, Vista, Waypoint; but it doesn't appear in the Constraint schema, see:

{
    "type": "PROPERTY CONSTRAINT SCHEMA",
    "constraints": {
        "type constraint": " wpg",
        "allowed values": [
            "Continent",
            "Region",
            "Zone",
            "City",
            "Lobby",
            "Activity",
            "Guild hall",
            "Area",
            "Point of Interest",
            "Dungeon",
            "Raid",
            "Instance",
            "Guild Puzzle",
            "Jumping puzzle",
            "Landmark",
            "Mini-dungeon",
            "Vista",
            "Waypoint",
            "Conquest",
            "Team Deathmatch",
            "Stronghold",
            "Strike Mission",
            "Murderball"
        ]
    }
}

Hence, setting the location type to "Dragon Response Mission" doesn't provide a link, see Dragon Response Mission: Metrica Province, and will also complain that it is an inproper value, see Special:ProcessingErrorList.

Any idea what's going on here? --Tolkyria (talk) 12:58, 18 November 2020 (UTC)

I saw the edits and it showed 2900 actions in the queue, but they are gone and I have no idea otherwise. —Kvothe (talk) 13:27, 18 November 2020 (UTC)

I made [[Property: Test]] with Dragon Response Mission and the new schema included it, then I copied that code over here and it still didn't work. lol. --BuffsEverywhere (talk) 18:25, 18 November 2020 (UTC)

I removed Murderball from the allowed values and the schema still didn't get updated. --BuffsEverywhere (talk) 18:39, 18 November 2020 (UTC)

It's somehow stuck. I doubt that it could be fixed with normal user tools. I'm not sure if the constraint schema could be updated manually by a sysop (especially Special:ListGroupRights Administrators (Semantic MediaWiki) and Curators (Semantic MediaWiki) actions); but then again it might be stuck again. So probably forcing it to rebuild by deleting and restoring the page could the best way to fix this (if it works). --Tolkyria (talk) 19:02, 18 November 2020 (UTC)

With Alex not being available for some time, Kvothe, can you give it a try and delete + restore this property page? I don't know any other method to fix this. --Tolkyria (talk) 20:32, 18 November 2020 (UTC)

Did so now, it is currently rebuilding. —Kvothe (talk) 22:59, 18 November 2020 (UTC)

Nope, still stuck. Checking the allowed values, I noticed that Lobby redirects to City#Lobby, we once had a somehow compareable problem with Property:Has achievement page, setting it to "<page>#<section>" resulted in an empty property. (Edit: Nope, nevertheless, having an own dedicated Lobby page wouldn't hurt, as setting "type = Lobby" will simply display City in the infobox) Otherwise, I'm running out of ideas.

Maybe remove all allowed values, delete + restore it, then set the allowed values; I don't know. Or ask Justin to run a backend smw repair command. --Tolkyria (talk) 23:38, 18 November 2020 (UTC)

Just started a Semantic MediaWiki Data rebuild based on wiki contents. If this does also not work out, we have to give it to Justin. —Kvothe (talk) 00:29, 19 November 2020 (UTC)

The rebuild is about 90% done. —Kvothe (talk) 11:16, 19 November 2020 (UTC)

I assume you performed this: smw:Help:Special:SemanticMediaWiki/Data rebuild. It states: "Also note that it is normal that the update progresses faster until it reaches 50%, since only property pages are refreshed during that part of the process. The actual update of all wiki pages starts at 50%." You mentioned a progression of 90%, the properties and hence their allowed values should have been already considered. Unfortunately the allowed values are still stuck.

I already added a bug report (okay, maybe a little bit too soon, expected the rebuild to be already finished, nevertheless I think it doesn't fixed it), see Guild Wars 2 Wiki:Reporting wiki bugs#Property's allows value are stuck. --Tolkyria (talk) 11:58, 19 November 2020‎ (UTC)

Alternatively, what about smw:Help:Special:SemanticMediaWiki/Object ID lookup and disposal: delete the property page, delete the property entity with the ID: 5730729 (hover the property at Special:Properties), then recreate the property page and hope. --Tolkyria (talk) 12:11, 19 November 2020 (UTC)

Did as you suggested. Then purged some pages to manually restore smw properties -> same error is back. Started a new rebuild to make other locations functional again. —Kvothe (talk) 12:43, 19 November 2020 (UTC)

For the time being I'm going to remove the "allowed values" constraints. I have also temporarily blanked the location type on the three Dragon Mission Response: xyz pages. Let's let everything naturally rebuild itself (currently: "Change propagation updates are pending (3512 jobs estimated)"). Once this completes we'll put the properties back on the DRM pages - firstly we'll check this occurs without the nasty little orange popup (and that Special:ConstraintErrorList is still clear - somewhat odd that it is currently clear even with the three popups?). Then we'll try re-adding the allows value constraints to this property page, and see if it reoccurs.

I did wonder if there was a limit to the number of "allows value" options (we could test this by removing "dungeons" as an allowed value for example, and adding DRM) but apparently unless we have this value set particularly low on Semantic Forms it shouldn't be an issue.

If this doesn't work, we can throw the wiki under a bus for a week and destructively rebuild the entire semantic database. -Chieftain Alex 15:38, 23 November 2020 (UTC)

It's still stuck, try {{#set: Has location type=Dragon Response Mission}} it will show a smw warning, although you removed the allowed values. See also the Constraint schema tab that's showing up and still has allowed values stored (note that this tab isn't showing up on any other properly working property). We already tried to remove an allowed value, BuffsEverywhere removed the allowed value Murderball and it was still accepted without a smw warning. Furthermore, we copied the property to [[Property:Test]] and there everything works; so it should not be some kind of limit.

Rebuilding the whole wiki makes zero sense in my opinion as everything else is working, on the Guild Wars 2 Wiki:Reporting wiki bugs I suggested a targetted attack: php rebuildData.php --page="Property:Has location type" -f -v especially -f, see smw:Help:Maintenance script rebuildData.php, but Justin wants to be sure that it isn't doing any harm elsewhere.

Something that we haven't tried yet is changing the type from page to text, maybe that's properly purging the property (although at the current stage I doubt it). --Tolkyria (talk) 16:37, 23 November 2020 (UTC)

Switching it to Text is something we should consider anyway, there's no particular reason to use Page. -Chieftain Alex 16:40, 23 November 2020 (UTC)

If we delete and create the page again (not by restoring) may that change anything internally? —Kvothe (talk) 17:53, 23 November 2020 (UTC)

I mean delete is a bit of a deeper "purge" but tbf should be very similar to completely changing the content. Got no problem with trying it. When you repaste the content, set it to text too. -Chieftain Alex 19:01, 23 November 2020 (UTC)

Possible solution 1: Delete the page, delete the property id, create this page with type "text" and no allowed values (Kvothe almost did this, just in the last step the page was restored instead, see Special:Log/smw/Kvothe and Special:Log/delete/Kvothe).

Another approach - possible solution 2: Move the property page. The question is: Will the internally property representation be updated correctly or is the internal representation already disconnected from this property page that nothing will happpen? Then create this page with type "text" and no allowed values.

Possible solution 3: backend approach, run some smw repair script, however the simple daily rebuild scripts are not enough.

Alex, since you deleted+restored the page Dragon Response Mission, all newly added allowed value won't be accepted, not just this page.

--Tolkyria (talk) 19:24, 23 November 2020 (UTC)

Edit: At this point I suggest to a backend solution only; whenever we are trying to reset this property, the templates that depend on this property are broken too (e.g. area categorization, area sort order, etc...) while the property remains bugged. --Tolkyria (talk) 14:38, 24 November 2020 (UTC)

Well the --page option is only going to recreate the properties for a single page, so Justin can try that without worrying too much. However I'm not sure --page is compatible with -f? Worst thing that happens is the templates go down for a few days, not so bad tbf. -Chieftain Alex 20:21, 24 November 2020 (UTC)

(Reset indent) I'm still in favour of a total reset. -Chieftain Alex 22:23, 24 November 2020 (UTC)

I was wondering if changing the pages content model from wikitext to say plain text and then back would do anything to rebuild/fix the schema? Or would that break anything or everything instead? Nightsky (talk) 22:39, 24 November 2020 (UTC)

Alex, I have the feeling that you somehow expect from me that I counter your suggestion. Do we really want to shut down the whole wiki for a day (or 12+ hours, I don't know) just because of this property? I mean everything else is working totally fine, I'm not aware of a single page that has a bugged properties (mostly due to properly running daily scripts, cleaning up outdated entities). I wouldn't go for it yet... I don't know... is this step justified yet?

Does SMW:Help:Special:SemanticMediaWiki/Object ID lookup and disposal say anything when asking for the ID = 7546920? Maybe you can check it and compare it with similar properties.

Since the backend solution (running repair scripts) doesn't yield any results, I would say that anything that "only" breaks this property (and its according pages) temporary but probably fixes the bug is a win. The problem is that the connection between this wiki page and the internal database representation got somehow lost (at least that's what I think), the question is how to restore this? Changing content model, well, it can't get really worse anymore.

Clarification: All properties which sets Allows value shows the Constraint schema tab, I falsely claimed that only this property does, see the property pages listed in Property:Allows value. --Tolkyria (talk) 23:03, 24 November 2020 (UTC)

Nightsky- RE content model: Worth a shot, shouldn't have any effect since it'll default to page type? "Property "Has location type" was altered and requires assigned entities to be reevaluated using a change propagation process. The property page has been locked until the primary specification update is completed to prevent intermediary interruptions or contradictory specifications. The process may take moment before the page can be unlocked as it depends on the size and frequency of the job queue scheduler."

Tolkyria- I'm not entirely against flushing the system but I see your point about trashing everything else in the meantime, especially if we don't know if it will work or not. I wasn't angling specifically for a response from you.

A couple of ideas I've had- (1) rename the property forever and delete this one and move on - I don't like this idea because I think the name is fine + updating templates is boring. (2) unset the property temporarily on all pages by disabling the infobox and map objectives templates. When the property is empty I'd bet my hat on it being receptive to updates. (3) Change to Type::text and see what happens. -Chieftain Alex 23:12, 24 November 2020 (UTC)

Intended or not, the content model change had the effect that the property type declaration got disabled, namely [[Has type::page]], and it now assumes the default property type page. Not sure if this makes a difference.

The property name is pretty perfect, somehow hard to replace this. So number 1) is the last option.

Indeed, 3) setting type to text and/or moving this property page without redirect + checking if the property id still exists on this pagename (see Special:Properties) and if yes the delete the id + creating this page with type text are definitely worth a try before rebuilding the whole wiki. --Tolkyria (talk) 23:22, 24 November 2020 (UTC)

Well we're experimenting right, even with our immense back catalogue of SMW trials and tribulations we haven't seen this particular error before. I've set it back to wikitext, and when it's unlocked (after processing) we'll try Text. -Chieftain Alex 23:28, 24 November 2020 (UTC)

Ok so "Text" didn't work.

Disposing of the table didn't work.

Moving the page to a new title didn't work (schema stubbornly attached to this title).

If I get time I will try and figure out the requirements for content in the smw/schema:____ namespace, maybe we can write the schema ourselves without the allowed values stuck-ness and attach it? -Chieftain Alex 00:01, 26 November 2020 (UTC)

Wow, what a persistent property. Are you sure that the smw/schema: namespace is doing what you expect? I haven't fully understand the potential of this procedere, but I can't find anything in the smw manuals related to modifying a property with it.

Off-topic: TIL how to group properties by setting {{#set:Is property group=true}} in the property category, see smw:Help:Property group based on smw/schema:Group:Schema properties. That might be worth adding. --Tolkyria (talk) 00:36, 26 November 2020 (UTC)

We'll need to ask the bcrats for the rights to edit the smw/schema namespace, as only SMW curators have that as editable. Unfortunately it's got a load of data validation which will stop invalid schemas, but I guess we should be able to copy a working schema tab from another property temporarily + see if it has any effect. -Chieftain Alex 00:59, 26 November 2020 (UTC)

Okay.

Browsing the smw manual, I found one last approach: [[Allows value list::location]] requiring [[MediaWiki:Smw allows list location]] to contain a unordered list of allowed values (see: smw:Help:Special property Allows value list). Maybe that allows to pass the value "Dragon Response Mission", I don't know if it's worth a try. --Tolkyria (talk) 01:09, 26 November 2020 (UTC)

Done but schema tab still looks the same atm. -Chieftain Alex 07:39, 26 November 2020 (UTC)

Two remarks:

• Pretty obvious, but now we have the conformation: it's not only the allowed values that are stuck, but everything, the property is still internally set as type page ("type_constraint": "_wpg",) while at the property page we already set type text (thus it should be "type_constraint": "_txt",).
• Due to moving and recreating this property without an active (and fast) rebuild (e.g. modifying the template {{location infobox}}) this property rebuilt extremely slow, resulting in temporarily bugged templates, especially the template {{waypoint}} might be currently unavailable. Hence, several wiki editors tried to "fix" those by editing it (e.g. incorrectly replacing it with {{map objective}}) instead of simply purging first the area page and then the waypoint-using-page. Please keep an eye on those edits and potentially revert those.

--Tolkyria (talk) 21:09, 27 November 2020 (UTC)

I'm thinking we should temporarily create a second property, set both properties (old and new name) in any location templates + then afterwards modify the call to pickup the new property. It will be annoying however it will give us full functionality back now; and we'll do a full wiki rebuild of the smw tables on a quiet day far away from the wiki AMA. I've created [[Property:Has location type 2]] for this.

Any idea which templates set property, anything other than Template:Location infobox? -Chieftain Alex 22:04, 27 November 2020 (UTC)

Good idea.

I'm pretty sure that only Location infobox sets this property. Ultimately, if the following to count queries give the same number then in fact we know that only the infobox does:

#Has location type: 5994 and #Has location type 2: 0

The templates which set the property "Has location type" are:

• Template:Location infobox
• Template:Map objective
• Template:Map link table

--Tolkyria (talk) 22:12, 27 November 2020 (UTC)

Edit: What do you think about setting the smw query parameter "@annotation" to e.g. {{Map objective}} using the query {{#show: {{#titleparts:{{PAGENAME}}}} | ?Has location type | link = none |<!-- NEW, ADDING THIS: -->@annotation}}, see smw:Help:Ask syntax/Annotation query marker. This will automatically execute this query after saving without requiring a second purge to receive the previously saved location type. Hence, the waypoint/vista subobjects should be set on the first edit/purge and doesn't require a second purge; one of the problems I stated in the remarks above. Alternatively, we could set a "#var:location" in the infobox and avoid asking for the location type at all. But in the end, anything that creates the subobjects with one edit/purge makes the display template {{waypoint}} less error-prone. --Tolkyria (talk) 22:24, 27 November 2020 (UTC)

Edit 2: Wow, it's literally in front of me and I don't get it. Of course Template:Map objective sets the location types "Waypoint" and "Vista". --Tolkyria (talk) 22:27, 27 November 2020 (UTC)

Never heard of @annotation, and given my paranoia about caching + smw (see: this entire page) I'm somewhat sceptical, but what the heck, let's add it anyway. -Chieftain Alex 22:28, 27 November 2020 (UTC)

It's a fairly new feature from SMW 3.0.0. Anything that uses {{#show: {{PAGENAME}}|?<property>}} after the infobox (and refers to a property set in the infobox), can be solved with a variable too (unless one needs e.g. some fancy smw sort). So maybe {{#if: {{#var:location type}}|{{#var:location type}}|<!-- else #show with @annotation -->}}, because indeed the caching + extra purging sounds a little bit fishy. I know that's a bit offtopic and not directly related to this property fixing, but this double purge requirement to properly create the map objective subobjects, makes the property resetting extremely tedious. --Tolkyria (talk) 22:37, 27 November 2020 (UTC)

Found one more template setting this property, added list above; usage numbers are the same now. --Tolkyria (talk) 23:00, 27 November 2020 (UTC)

Template:Location infobox
Template:Map objective
Template:Drop table
Template:Dropped by result format
Template:Event infobox
Template:Gathering node
Template:Interactive map
Template:NPC service table result format
Template:Vendor list result format
Template:Vendor item table result format
Template:Vendor table
Template:Waypoint
Template:Point of interest
Map completion/table
Guild Wars 2 Wiki:Projects/Cartography

Template:Parse location -- 2014 template unused, consider deleting
Template:Location tree -- unused, maybe move to relyk's userspace with formatting template too
  Template:Location tree result format
User:Relyk/SMW/locationtree -- earlier version of the same
Template:Location table -- not used anywhere, another relyk template. has some subtemplates:
  Template:Location table row result format
  Template:Area location result format
  Template:Hero challenge result format

User talk:Vili
User:AnastashaRomanov/Sandbox
User:Blackice/templates/area points of interest
User:Blackice/templates/waypoint optional chat link
User:Dr ishmael/areas
User:Relyk/Jump list
User:Relyk/SMW/query
User:Relyk/mapobjective
User:Relyk/sandbox/zone outline
User:Relyk/stats

(Reset indent) I think these are the templates I'll need to update. There's a couple of weird templates in the middle of this list which are unused, could delete them instead. -Chieftain Alex 12:27, 28 November 2020 (UTC)

I've now updated the top group in the above list.

Of course the little error bubble will still appear on the Dragon Response Mission pages - do we want to unset the property from location infobox for the time being, hide it with CSS, or something else? -Chieftain Alex 17:56, 28 November 2020 (UTC)

Nice, so I think only group 1 needs temporary adjustments, probably wrap the examples of unused templates (group 2) or userspace occurences (group 3) into nowiki tags (if we go crazy on this property).

However, I moved the reward tracks to group 1. It allows to automatically extract the fields "Region"/"Zone"/"Dungeon" from the name and hence is used on all geographically related reward tracks, e.g. Drizzlewood Coast Reward Track will display the field ;Zone :[[Drizzlewood Coast]] in the infobox. I think that's a nice feature, especially since most of the time the related geographical page isn't noted in the intro text.

We can put the Has location type into an {{#if: {{#set: Has location type={{ucfirst:{{{type}}}}}}} }}, this will hide the smw warning but still shows it in Special:ProcessingErrorList. Should we add allowed values to Has location type 2?

What about the map objective subobjects for vista and waypoint, should we define the variable "location type" in the infobox and reuse it there or try the @annotation? In order to avoid double purges, resulting in faster updates (only one purge, rather than purging a page twice), less confusion by wiki users when the {{waypoint}} isn't working again and ultimately less work for us. --Tolkyria (talk) 18:58, 28 November 2020 (UTC)

All that logic in the reward track infoboxes, just to add what appears to be a simple link is kinda excessive imo. I'd really like to start clamping down on using excessively complicated wikicode in templates. I won't argue about this particular template but I want to note this anyway.

Adding "Allowed value" to #2 - no thanks, it works without + that's exactly how the last property blew up. #if to hide the statement sounds ok.

@annotation - go ahead if you know where to place it, I don't. -Chieftain Alex 19:59, 28 November 2020 (UTC)

Removed "Reward track infobox" from the list.

Okay. --Tolkyria (talk) 21:15, 28 November 2020 (UTC)

Added Template:Interactive map to the list (not sure if this query is actually required or it can be retrieved from the api). --Tolkyria (talk) 22:17, 28 November 2020 (UTC)

Good spot on that template. iirc the region is set wrongly on many of the maps between v2/maps (where the high level continent/region/floors should be obtained from) and the v2/continents (where every bit of data is). Seems a bit overkill to check that that the regionID is actually a region, but it works. -Chieftain Alex 00:12, 29 November 2020 (UTC)

Post update

So is this alright now? I can't remember how to check if its borked or not. (https://wiki.guildwars2.com/wiki/Special:Browse/:Dragon-5FResponse-5FMission:-5FMetrica-5FProvince looks ok) -Chieftain Alex 17:35, 17 April 2021 (UTC)

It does seem to have gotten unstuck. Special:ProcessingErrorList (taken from above) is empty. {{#set: Has location type=Dragon Response Mission}} (also taken from above) also doesn't produce any error anymore. Could probably try adding the Allows values back? Nightsky (talk) 18:55, 17 April 2021 (UTC)

Benefit of using Allows value still eludes me. Don't we set most of these via infoboxes with checks anyway. -Chieftain Alex 22:29, 21 April 2021 (UTC)

Well the {{location infobox}} it initially was a problem with didn't (still doesn't) check what was specified in any way (appart from if it's a point of interest or not specified at all do this or that). The only check i think there is are the alows values, though i could be wrong with that. For the location infobox at least though:

:{{#switch: {{lc:{{{type|unknown}}}}}
  |point of interest = [[Point of Interest]] {{#set:Has location type=Point of Interest|Has location type 2=Point of Interest}}
  |unknown=''Unknown''
  |#default = [[{{ucfirst:{{{type}}}}}]] {{#if: <!-- hide smw warnings from bugged "Has location type" --> {{#set:Has location type={{ucfirst:{{{type}}}}}|Has location type 2={{ucfirst:{{{type}}}}}}} }}
}}

Nightsky (talk) 22:59, 21 April 2021 (UTC)

Any objections to switching from {{ifexists|Property:Has location type 2|[[Property:Has location type 2]]|[[Property:Has location type 2]]}} back to this property then? Because if not then i'll do that sometime soonish. Nightsky (talk) 17:45, 30 April 2021 (UTC)

None. -Chieftain Alex 18:05, 30 April 2021 (UTC)

Updated all pages in the first part of the table higher on this page. DJemba (talk) 20:10, 30 April 2021 (UTC)

I mean i meant to wait untill about sunday evening to give people time to bring forth objections, if any, but i was sad it was already mostly done instead. So guess i'll see what's left that i can find (in the main and template namespace) before removing the setting of property #2 now then instead. Nightsky (talk) 17:00, 4 May 2021 (UTC)