User Details
- User Since
- Oct 25 2014, 5:39 AM (495 w, 5 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Jongfeli [ Global Accounts ]
Nov 24 2022
Dec 9 2020
@Nikerabbit, thanks for the fix. This also works in MW-1.35.0
Oct 22 2020
Oct 20 2020
I am a little confused. I remembered this problem but back then (in 2018) it seemed to be fixed by adding the following to a form:
Jun 30 2017
A short update for the people interested. After some testing we found out that when using mod_fcgid.so instead of php7apache2_4.dll to handle PHP it works just fine and more important it keeps working fine.
Feb 28 2017
@smkent could you be more specific on your configuration, which linux distro are you using and which version?
Jan 24 2017
Ok, did some digging again. I tested this on:
Dec 30 2016
Hello @Paladox, thanks for your fix. I understand that restarting Apache helps but only for a short while. After x time the same things happens again.
Dec 23 2016
Ok, I have spend some time trying to debug this one and found out that I can reproduce the above error only when Zend OPcache is enabled. The fault pops up after x time.
Dec 7 2016
Dec 6 2016
Oct 11 2016
Sep 8 2016
When you wrote "most wiki's using SF work exactly as you describe", do you mean that most wikis use default values when editing existing pages?
Hello Yaron, a comment:
Sep 2 2016
Jongfeli: I really don't think it's true that default values were added when editing existing pages, in all SF versions before 2.4.1. In any case, as I've said before, it doesn't matter what SF used to do. (I thought you agreed with me on that, but I guess you changed your mind.)
Aug 31 2016
My work with SMWikis would not be possible and the acceptance in my department for such wikis would not be there without Semantic Forms. Therefore, I am immensly grateful, that this powerful extension exists and that Yaron and others spend so much time maintaining and developing it.
Well you are making it very hard for me here :) The saveblank option was merely a suggestion.
Aug 30 2016
Hello Yaron, are there any plans to get the default value fixed for all pages, new and existing like discussed here?
Jun 20 2016
I understand but in my opinion it is the right behavior because that is where the default value is for. However you are right, in your example Bob will be working in the "wrong" department after Charlie edited his page :) Which is probably incorrect. An SMW wiki is as good as the people who build it:
Jun 17 2016
Ok , you are right, the past is the past :)
Yes that is possible but the feature is to be able to alter the parameters in the field tag including the default in a form and that these changes apply to existing and new pages. This feature has always been part of SF before 2.7, you where always able to alter forms anyway you wanted and this also applied to the defaults.
Ok, well initially the blank value will not be replaced by the default when the page is edited. Only when the page is edited again the default will be used because, by that time, the field is not on the page anymore. Any empty field that is stored on the page will disappear anyway when pages are edited with SF 2.7 and higher.
No I don't think so. Fact is that empty fields are not saved on the page anymore since SF 2.7. To me this seems to be the correct behavior.
Jun 16 2016
No, I do not think it is wise to change this empty field behavior back to he way it was years ago. The default values in the field tag used to work just fine on new and existing pages, it is not a new feature I am merely trying to fix it :)
Jun 15 2016
No, the field is not in the page source when it has a blank value. you can test this in the SMW sandbox by entering a value for Defaultvalue1 saving the page and then blanking the value in the next edit.
Jun 14 2016
Yes I did but I think it is the story of the chicken or the egg. If your example page was created with SF without a value for ABC then it is not saved on the page like ABC= (no value). You can not check something that is not there. If you would manually add ABC= (no value) to the page in the template call and the field has a default value in the form then it will be shown in the form as soon as you edit the page with SF. If you then delete the default value again and save the page with no value for ABC it will be deleted from the template call. I must say that we always use parameters with an empty default on its own like: {{{parameter|}}}.
#1. I don't understand. With the patch applied I tried to replicate this but on our wiki the default values used in the form are showing up in the actual form and on the saved page. The patch seems to be working fine. It works with the edit with form tab (for existing pages) or {{#forminput:... for new and existing pages. I tried this on a blank wiki with the following extensions (installed with composer).
Jun 13 2016
Yes you are right but in the past I tried this under windows but did not succeed but now it seems to have worked, I hope :)
Nov 12 2015
Oct 23 2015
It has been fixed with this commit. Thanks Yaron.
Sep 30 2015
Sep 25 2015
Sep 7 2015
Aug 12 2015
Jul 21 2015
Jun 15 2015
May 31 2015
May 25 2015
May 1 2015
Apr 23 2015
No, no Javascript errors. I do see a difference in the HTML code, maybe that can be of help.
Apr 12 2015
Apr 3 2015
Apr 2 2015
Apr 1 2015
Mar 29 2015
Mar 26 2015
Mar 24 2015
Feb 17 2015
@ori yes I am OK with that, no problem. The problem was that the latest version was in the tar download for MW 1.24.1 but that does not seem to be the case anymore.
Jan 27 2015
See: T85794
SyntaxHighlight version from April 2014 works like expected, it has basically no impact on performance. Below that version compared to Master without any caching enabled. It adds +/- 600 ms to loading times.
Jan 26 2015
Added one more test on the same hardware comparing the same setups but with and without SytaxHighlight enabled on an otherwise "empty" wiki (see: sandbox). It is not a specific HHVM "problem", it affects all solutions except XCache with object caching enabled. It seems that the "cause" is javascript that takes a relatively long time to load (see below).
Small update. What triggered me was the fact that HHVM is faster then any other caching solution we used before. We are running our wiki on a windows server so HHVM is not happening at the moment. To compare and build a case to switch to a Linux OS I compared the different solutions to show what an impact it can have. On a clean wiki HHVM is faster then XCache with object caching enabled but when SyntaxHighlight is enabled this changes dramatically. Posted the results from yesterday in my sandbox.
Jan 25 2015
It has not been brought op on the talk page as far as I know. I have access to our production wiki tomorrow and will do the same test and post the result here, when time permits. But when this is really happening it should be relatively easy to reproduce on any "test" wiki. It would be a good thing if somebody else can confirm the same behaviour.