[04:32:41] Hello, is anyone logged in? [04:32:57] !admin [04:33:25] hello? [04:41:25] yo!!? [04:44:56] !ADMIN [04:45:11] !admin [10:33:54] i could use some help understanding the {{ ... }} block created by Semantic Forms ... for they don't seem to work anymore for me, and after looking closer i can't eaven find documentation about telling me how this would be valid wiki syntax [10:36:06] the block seems to be of the form "{{\n|property=value\n|property=value}}" - however, according to http://semantic-mediawiki.org/wiki/Help:Properties_and_types#Silent_annotations_using_.23set i would expect some usage of "#set" - and there is no mentioning about the category [11:03:59] hrmm ... could it be that the Semantic Forms are not compatible at all with current Semantic Mediawiki? [11:05:49] because i now started from scratch ( fresh installed "everything", fresh and new wiki, ... ) and the forms just don't work at all [11:07:14] "not work at all" meaning "queries don't see any semantic info entered via form" [11:37:39] hrmm ... a bit too silent in here for my taste ... [17:12:37] heya.. I am still having problems with a moved wiki. I fixed most of the problems by reinstalling the whole wiki and dropping a certain cache table in the database (mw_module_deps). The only remaining problem is SemanticResultFormats (the calendar part) trying to load a file from wiki/extensions/SemanticResultFormats/formats/calendar/resources/images/right-arrow.png while the wiki is located at / (not wiki anymore). So somewhere SRF seems to [17:12:37] cache that location [17:13:13] SRF tries to load some other files (left-arrow.png and a stylesheet) from that path aswell [17:13:24] which breaks all calendars in the wiki [17:13:38] editing and resaving the calendar pages didn't help [17:16:25] is there any table like that in SMW/SRF? grepping MySQL is cumbersome [17:17:48] sven^: check $srfgScriptPath [17:19:18] where is that variable set? [17:19:21] I never touched it [17:20:07] sven^: Dunno. Just greped for right-arrow.png and found calendar usin that var [17:20:18] yeah, found that aswell [17:20:30] but can't find the location where it's set.. [17:20:34] well, next grep [17:20:36] mom [17:21:16] $GLOBALS['srfgScriptPath'] = ( $GLOBALS['wgExtensionAssetsPath'] === false ? [17:21:16] $GLOBALS['wgScriptPath'] . '/extensions' : $GLOBALS['wgExtensionAssetsPath'] ) . '/SemanticResultFormats'; [17:21:57] so check wgExtensionAssetsPath and wgScriptPath [17:24:54] this is getting wierd. [17:25:06] 29 $wgScriptPath = ""; [17:25:15] that's from my LocalSettings.php [17:25:50] adding this to SemanticResultFormats.php 40 error_log( "ScripPath:" . $GLOBALS['wgScriptPath'] ); [17:26:25] shows [...]smod_fcgid: stderr: ScripPath:/wiki, [...] [17:26:30] wth. [17:27:43] sven^: Try searching through your MW install for /wiki :D [17:27:51] I did that already [17:27:55] nothing there [17:28:14] I think the problem is that SRF uses that GLOBALS[''] stuff [17:28:23] instead of the proper $wgScriptPath [17:28:29] only question is: where is it set? [17:28:40] No offense, I think you are wrong [17:29:31] 40 global $wgScripPath; [17:29:31] 41 error_log( "ScripPath:" . $GLOBALS['wgScriptPath'] . " or $wgScriptPath" ); [17:29:41] (SemanticResultFormats.php) [17:29:54] ===> ScripPath:/wiki or , referer: [...] [17:30:09] MediaWiki is a mess. [17:30:33] agreed! :D [17:31:35] There might be a problem in the order of when stuff is called [17:32:11] the big question how the variable is set [17:32:16] the GLOBALS thing [17:32:23] Try changing the $wgScriptPath in includes/DefaultSettings [17:32:34] obviously somewhere the old path is cached [17:32:37] hmm, ok [17:32:51] maybe it's a default, yes.. [17:34:15] wow, this sucks [17:34:18] really [17:35:22] so a) MediaWiki is broken for not setting GLOBALS['wgScriptPath'] to the value that is set in LocalSettings.php (maybe it's deprecated?) and b) SRF is broken for using that value instead of the proper $wgScriptPath [17:36:06] or maybe there are "$reasons" to use that variable [17:36:18] They are both broken, but not in the way you describe [17:37:09] $GLOBALS is an array holding all global variables, so on a global scope $wgScriptPath===$GLOBALS['wgScriptPath'] [17:37:17] No, the culprit is composer [17:37:35] Or MWs and SRFs handling of it [17:37:57] why does that GLOBALS variable even exist? [17:38:39] To have access to globals [17:39:05] e.g. depending on how you load files this may or may not be the case for the $wgFoo form [17:40:39] wait.. maybe I missunderstand the process... shouldn't MW set up all variables in a proper way? Like using values from LocalSettings or defaulting to includes/DefaultSettings? [17:41:17] Let me quote Facebook: It's difficult [17:41:26] In principle, yes, of course [17:41:27] since running the extension in another way than including it should always lead to exceptions that setup process should always happen, right? [17:41:38] but different extensions have different requirements [17:41:53] some need variables to be set before they are loaded [17:41:55] some after [17:42:10] now with composer there is the problem of when you set those variables [17:42:22] where does composer even come in? [17:42:25] it was decided to first load composer-instaled extensions [17:42:32] then run LocalSettings.php [17:42:43] I mean, how does composer include the code? [17:42:49] (never had a proper look at it) [17:43:20] Or was it the other way around? [17:44:00] No, like I said, composer first, then LocalSettigns [17:44:15] have a look at WebStart.php if you're interestet [17:44:21] ok, I will [17:44:23] interested* [17:44:30] but not right now [17:44:48] got a meeting in 15 mins, need to shower and actually wanted to do some shopping before that.. [17:44:55] but I guess MW screwed me [17:45:03] have fun. I guess I'll write a bug repirt now [17:45:10] *report [17:45:58] kk, thanks for you help [17:46:06] np [17:47:04] ahaha [17:47:11] $verboten = array().. [17:47:22] as a German, I think that's funny [17:47:38] where does that come from? [17:47:50] includes/WebStart.php [17:48:20] so someone just didn't care about naming conventions and used a german word describing a variable.. that's funny [17:48:23] hmm, you most have a different version. [17:48:36] 1.23.2 [17:48:51] newest stable, a week or 2 ago [17:49:57] Ah, so look at it a bit more. Can't find it anymore in 1.24 :) [17:57:25] but actually LocalSettings IS loaded when running SRF, so it's LocalSettings and then Composer [17:57:39] just the GLOBALS array isn't defined properly [18:00:17] forget that GLOBALS array. It is a language feature. If there is a global variable, you will fiond it in GLOBALS [18:03:32] hmm [18:03:41] but wgScriptPath is not global at that point [18:03:47] or at least not accessible [18:03:58] and when it is, it has a different value [18:04:42] anyway, need to go. Maybe I read some code later to see what's going on or maybe I read some less messy non-MW code for fun... ;) [18:04:48] $wgScriptPath is undefined, GLOBALS['wgScriptPath'] is not [18:05:03] :D bye [19:11:47] Hey folks! [19:13:07] I'm facing something unusual with SMW. The #set_internal function is not being parsed, but shown within the content page [19:14:05] eliezerb: Do you find SMW on Special:Version? [19:14:35] FoxT: 1.8.0.5 [19:15:17] eliezerb: What about the SemanticInternalObjects extension? Is it there? [19:15:47] Oh, I don't think so [19:15:56] There you go. :) [19:16:12] FoxT: Thanks :) [22:34:36] (PS1) Yaron Koren: On second thought, make the next version 2.8 instead [extensions/SemanticForms] - https://gerrit.wikimedia.org/r/156986 [22:35:04] (CR) Yaron Koren: [C: 2 V: 1] On second thought, make the next version 2.8 instead [extensions/SemanticForms] - https://gerrit.wikimedia.org/r/156986 (owner: Yaron Koren) [22:35:50] (CR) Yaron Koren: [V: 2] On second thought, make the next version 2.8 instead [extensions/SemanticForms] - https://gerrit.wikimedia.org/r/156986 (owner: Yaron Koren)