Hi, if you already know the target page's name, #formlink is not the recommended approach - instead, it's better to link via a semantic property, that has a "default form" specified: that way, the link will work correctly both before and after the target page is created.

Interesting. In this case though, the form name IS NOT a property - it is nothing more than an index to multiple pages of the same type in order to maintain unique identifier information.

For example in this case this is Participant information. The numbers of particpants is constantly growing - and may have no single unique identifier (example 2 participants with same name). Unique identifier information is deliberately NOT kept (e.g., SSN or other privacy identifiers). While this solution would work in this particular case, the identifier is the same name as the page, but a different namespace.

Setting to "WONTFIX" - the red-link approach turned out to work for this case, after an additional conversation.

Uh, no it didn't fix the problem, it gave me an alternate solution - which I can't use because I would have to go back and change every place #formlink is used - and the users like the "button" versus the link - they've specifically told me so.

I can (and will) maintain this as a branch. In general, I think code should be "bullet proof", so that if someone uses a feature in compliance with the documentation, the code should not generate an error.

In this case, if you use the #formlink (as specified):

• 'formlink' is called as: *
  • {{#formlink:form=|link text=|link type=|query string=}} *

It will generate an error, and there is no other way to create an add via a button versus a link.

Oh, and I'm not the only one having this problem: http://sourceforge.net/mailarchive/forum.php?thread_name=op.u8odx7sy7wtwxn%40mail.libero.it&forum_name=semediawiki-user

Is using "target=" within #formlink part of the documentation? I don't believe it is. Also, in that email you cited, everyone else is talking about the "cancel" link - totally unrelated to this issue.

Fixes both SF_AddData.php and SF_EditData.php to allow "mixed" url for backward compatibility

Created a patch that fixes both SF_AddData.php and SF_EditData.php to allow "mixed" url for backward compatibility for #formlink and direct URL access.

attachment Allowformlinks.patch ignored as obsolete

Allows use of "target=" in query string

Simplified and moved into single area of SF_FormEdit.php

Attached:

I'm reduced to flat out begging! I'm re-opening this because it's raised its ugly head again - and there's simply to alternative because of its extensive use in so many of our wikis.

This new patch allows the use of "target=" in the query string. It has no performance impact and does not add to the complexity of the existing code (it just moves the check for "target_name" two lines down.

Most importantly, it provides for backward compatibility of a widely used feature (at least in our wikis) for which there is no other alternative other than a redlink (they REALLY like the buttons as it provides a visual cue to which information sets do not have completed associated sub-forms).

Patch attached (Above).

PLEASE, PRETTY PLEASE???

Now that I think about it, the code in SF that transforms the red links could also add a CSS class to those links, so that CSS styling could be added to make those links look like buttons (see here, for example - http://www.webpelican.com/web-tutorials/css-buttons-tutorial/). How does that sound?

Uh, I guess, but it doesn't solve my backward compatibility problem. If it's that much trouble, I'll just maintain the patch.

Setting back to "WONTFIX"; enjoy your hacks.

OK, it's your baby, and I'm screwed.

I was beginning to think that SF was a stretch for this application. Documentation has always been weak, leading to innovative solutions for problems that are not fully documented - such as was done in this case.

I have no idea how many other places we may have "stretched" SF and frankly, it would be poor management to wait for other upgrades to find out.

Knowing forward compatibility is going to be a problem really reinforces looking for a more appropriate solution.