[Bug 56310] Properties not being set on pages in custom namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=56310 MWJames changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from MWJames --- Another example is [1] where the "Demo" custom namespace is used therefore functionality is provided with the current SMW master (1.9). For further help, see [2]. Until a specific example is provided where the custom namespace functionality does not yield expected behaviour, this bug is being set to be invalid. Feel free to reopen this bug with an appropriate unit test or a repeatable test description against SMW master (1.8.x is no longer under active development). [1] http://semantic-mediawiki.org/wiki/Demo:Berlin [2] http://semantic-mediawiki.org/wiki/Help:Troubleshooting#Missing_data_on_custom_namespaces -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 56310] Properties not being set on pages in custom namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=56310 Neill Mitchell changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #5 from Neill Mitchell --- Hang on, you can't just close this! Two people have reported this regression on the current stable release version of SMW. SMW 1.9 is not released. A lot of people are using 1.8.0.5 and will be going forward. So are you saying all support for the current release version of SMW has now been dropped? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 56310] Properties not being set on pages in custom namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=56310 Andre Klapper changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Andre Klapper --- Neill: Comment 4 asked to provide a reproducible testcase that can be triggered against SMW master. It is up to developers to decide which versions they still support, and as written, 1.8.x is no longer under active development. Closing as WONTFIX for 1.8.x for the time being (feels slightly more appropriate than INVALID) until it has been shown that the problem still happens in more recent versions. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 56310] Properties not being set on pages in custom namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=56310 --- Comment #7 from [[kgh]] --- To add to this: I cannot confirm this problem. Just two weeks ago I set up a custom namespace including semantic capability with and the same setup (SMW 1.8.0.5, MW 1.20.8, PHP 5.3.3, MySQL 5.1.66 on Store3 and I am able to set properties galore. Are you sure you defined the custom namespace *before* the inclusion of Semantic MediaWiki and set the namespace with semantic links parameter e.g. $smwgNamespacesWithSemanticLinks[NS_PRIVATE] = true; *after* the inclusion of Semantic MediaWiki. Make also sure that you do not set an array for this, since this indeed does not work. This parameter must be set individually for every namespace (regular as well as talk) in LocalSettings.php. After an upgrade to MW 1.21.3 everything is still running smooth. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 56310] Properties not being set on pages in custom namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=56310 --- Comment #8 from MWJames --- (In reply to comment #5) > SMW 1.9 is not released. A lot of people are using 1.8.0.5 and will be going > forward. So are you saying all support for the current release version of SMW > has now been dropped? I have stated that "1.8.x is no longer under active development" which means that any issues reported are only verified against the current SMW master implying that functionality and fixes are provided for SMW master only. In general only security fixes are back-ported but any developer is free to provide fixes and back-ports for any release but the developer should make sure that fixes are compatible with the current master as it runs a "battery" of unit tests [1] which do not exists in releases before SMW 1.9. [1] https://travis-ci.org/SemanticMediaWiki/SemanticMediaWiki -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 56310] Properties not being set on pages in custom namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=56310 Neill Mitchell changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #9 from Neill Mitchell --- Perhaps I'm getting a bit old school, but I feel there is some fundamental principal of software engineering being missed here. The issue was raised against the current stable release version of SMW as detailed here: http://semantic-mediawiki.org/wiki/Help:Download This is not "active development", it is bug fixing. People cannot always run the latest and greatest versions of everything on their servers, especially when there are a number of interdependencies involved. The stable release version is going to be around for a while yet and should never get left hanging out to dry. Reported issues should not just be closed out of hand. If the issue is not present with the SMW master that's great, but the bug was not raised against SMW master so providing a test case is not relevant to the report. I think some clarity is required here. Are you suggesting that people have to constantly update their instances to SMW master in order to receive bug fixes going forward? What is going to happen when SMW 1.9 is released and you start working on 1.10? Are you then not going to do any bug fixing on the newly released 1.9? Will be users have to use the 1.10 branch to receive fixes for any issues that arise with 1.9? If this is a new policy going forward, then I think people need to be made aware of this right now before committing themselves to a path that may not be suitable for them. I suggest further discussion should be made on the mailing list and a support policy published. I'm curious as to who the developers being referred to are? I thought SMW was a community project? So in this spirit, I am re-opening this issue in case there is someone running the current stable release version with the time and interest to investigate and fix if required. If the bug is closed, it will not be seen by someone who might like to contribute. If the issue is not solved, or becomes irrelevant going forward we can review. I'm not trying to be difficult here. I just really don't want to see SMW adopting the constant beta model practised by the likes of Google et al. Quality inevitably suffers and people get fed up and lose interest. Perhaps I've misunderstood and this is not the path that has been chosen. kgh - Thanks for your suggestions, but my set up looks correct. The issue started after upgrading to from 1.8alpha to 1.8.0.5. Perhaps it is an upgrade issue. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 56310] Properties not being set on pages in custom namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=56310 --- Comment #10 from MWJames --- (In reply to comment #9) > This is not "active development", it is bug fixing. People cannot always run > the latest and greatest versions of everything on their servers, especially > when there are a number of interdependencies involved. The stable release > version is going to be around for a while yet and should never get left > hanging > out to dry. Reported issues should not just be closed out of hand. This was not the case no examples were provided that would allow to verify the claim made, on contrary examples were cited that showed a working functionality leaving the bug to be closed based on the given evidence rather than a "out of hand" manner. > If the issue is not present with the SMW master that's great, but the bug was > not raised against SMW master so providing a test case is not relevant to the > report. If no test case is provided and the reported error can't be verified with the current master, how would you decide and test that a problem is fixed or not. A unit test exists to verify an assumption about an expected behaviour. > I think some clarity is required here. Are you suggesting that people have to > constantly update their instances to SMW master in order to receive bug fixes > going forward? I'm not suggesting anything, I stated that "any developer is free to provide fixes and back-ports for any release" which means you are free to install which ever version works best but software patches (if provided) should be "compatible with the current master". > What is going to happen when SMW 1.9 is released and you start working on > 1.10? > Are you then not going to do any bug fixing on the newly released 1.9? If you ask me personally, once 1.9 is released I will focus on other tasks that are not related to 1.9 (but this is just me). > Will be users have to use the 1.10 branch to receive fixes for any issues > that > arise with 1.9? Again, "any developer is free to provide fixes and back-ports" which means that if a developer sees the need for a back-port he/she is free to do so. > If this is a new policy going forward, then I think people need to be made > aware of this right now before committing themselves to a path that may not > be > suitable for them. I suggest further discussion should be made on the mailing > list and a support policy published. Please feel free to do so, it is a community project and I hope that people will commit themselves to a broader support infrastructure and more developers take up the opportunity to be involved but please don't expect core-developers to restrict themselves to invest their volunteer time on issues they might not seem relevant to them. See also [1]. > I'm curious as to who the developers being referred to are? I thought SMW My previous statement "any developer is free to provide fixes and back-ports" includes all developers who want to provide software improvements (back-ports, fixes, new developments etc.). It is a volunteer and community project therefore anyone is encouraged to extend and improve the software. Having said this, probably most core-developers will focus on evolving the current master aiming towards objectives stated within the roadmap [1]. > was a > community project? So in this spirit, I am re-opening this issue in case > there > is someone running the current stable release version with the time and > interest to investigate and fix if required. If the bug is closed, it will > not > be seen by someone who might like to contribute. If the issue is not solved, > or > becomes irrelevant going forward we can review. Maybe the bug title should reflect that is an issue with 1.8.x (but apparently it is not citing the example of kgh). > I'm not trying to be difficult here. I just really don't want to see SMW > adopting the constant beta model practised by the likes of Google et al. > Quality inevitably suffers and people get fed up and lose interest. Perhaps This is why I ask for "an appropriate unit test or a repeatable test description" so that it can be verified, fixed, and tested to improve overall quality and stability. > I've misunderstood and this is not the path that has been chosen. SMW is a volunteer project, expecting a support infrastructure like that of a commercial product is more suited and left to specialised service providers [2] (this is not a hidden advertisement as I'm not involved in any professional support). [1] http://www.mediawiki.org/wiki/Backporting_fixes [2] http://semantic-mediawiki.org/wiki/Roadmap [3] http://semantic-mediawiki.org/wiki/Professional_support PS: I will further excuse myself from this bug in order to focus on more pressing issues. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org
[Bug 56310] Properties not being set on pages in custom namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=56310 Al Johnson changed: What|Removed |Added CC||alj62...@yahoo.com --- Comment #11 from Al Johnson --- I too had this very same problem after an upgrade to SemanticBundle 1.8.0.5. But, I was able to finally get it to work with kgh's suggestions, specifically: "...set the namespace with semantic links parameter e.g. $smwgNamespacesWithSemanticLinks[NS_PRIVATE] = true; *after* the inclusion of Semantic MediaWiki. Make also sure that you do not set an array for this, since this indeed does not work. This parameter must be set individually for every namespace (regular as well as talk) in LocalSettings.php." On a side note: I completely agree with Neill's comment #9... but his expectations are not "old school" at all, but proper and axiomatic. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 56310] Properties not being set on pages in custom namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=56310 --- Comment #1 from Neill Mitchell --- This is working on an older wiki running MW 1.19 and SMW 1.7 with SQLStore2. So it looks like this is definitely a break. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 56310] Properties not being set on pages in custom namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=56310
MWJames changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever confirmed|1 |0
--- Comment #2 from MWJames ---
Just checked (by hand, don't have time to write a test for this) with:
MediaWiki1.19.7
Semantic MediaWiki (Version 1.9 alpha-3) (SQLStore3)
## LocalSettings (before any extension specification):
define("NS_FOO", 160 );
define("NS_FOO_TALK", 161 );
$wgExtraNamespaces[NS_FOO] = "Foo";
$wgExtraNamespaces[NS_FOO_TALK]= "Foo_talk";
$wgNamespacesWithSubpages[NS_FOO] = true;
## SEMANTIC MEDIAWIKI
...
$smwgNamespacesWithSemanticLinks = array(
NS_FOO => true,
)
Adding a page Foo:WgExtraNamespaces with [[Has test on::WgExtraNamespaces]]
will yield for [1] a WgExtraNamespaces#160# entry. 160 indicates NS_FOO and it
also shows that SMW has successfully annotated the page WgExtraNamespaces
(namespace NS_FOO) with a "Has_test_on" property.
[1] api.php?action=browsebysubject&subject=Foo:WgExtraNamespaces
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 56310] Properties not being set on pages in custom namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=56310 --- Comment #3 from Neill Mitchell --- Hi. I've replicated your set up and the Has test on property is not set :( I notice you are running an alpha version of SMW 1.9.3. I'm running the stable release version - 1.8.0.5. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
