Discovered while debugging another developer's code ... sigh

Given a controller defined with a single getter/setter

public with sharing class SfseCtrlExample {
  public String foo {get; set;}
  public void doAction() {}

Given a VF page using a commandButton and commandLink that passes a parameter to existing (foo) and non-existing (bar) controller properties

<apex:page id="SfseCtrlExample" controller="SfseCtrlExample">
 <apex:form id="theForm">
    <apex:outputText value="foo paramVal={!foo}"/>
    <apex:commandButton value="Do Action" action="{!doAction}" reRender="theForm">
        <apex:param name="p1f" assignTo="{!foo}" value="fooValCB"/>
        <apex:param name="p1b" assignTo="{!bar}" value="barValCB"/>
    <apex:commandLink value="Do Action (CL)" action="{!doAction}" reRender="theForm">
        <apex:param name="p2f" assignTo="{!foo}" value="fooValCL"/>
        <apex:param name="p2b" assignTo="{!bar}" value="barValCL"/>

When either commandButton or commandLink clicked

  • The assignTo="{!foo}" successfully passes the value to the controller (for commandButton, requires the well-known reRender workaround)

But no compile-time or run-time error results for the assignTo="{!bar}"

I can sort of see why there's no error for apex:param nested under apex:commandButton as that is not supported, but given that the VF page compiler can check for missing properties and methods in other components, why is it not for apex:param?

  • 1
    It's a bug. You'll have to open up a case and report it as such.
    – Adrian Larson
    Commented Dec 26, 2018 at 23:07
  • support case 21169177
    – cropredy
    Commented Dec 27, 2018 at 1:12
  • after 10 days, level 2 support gives me daily updates that read: I have followed up my internal team for your concern and will notify you as soon as I have an update from them. - I just want SFDC to ack this as a doc error
    – cropredy
    Commented Jan 11, 2019 at 20:02
  • That sounds completely familiar. I think the record for me is something like 50 straight daily messages that looked just like that.
    – Adrian Larson
    Commented Jan 11, 2019 at 20:05
  • We further escalated this case to R&D team -- ooh!
    – cropredy
    Commented Jan 15, 2019 at 21:23

2 Answers 2


This is not strictly a bug, at least not in Visualforce terms. Allow me to explain. Unlikely many other aspects of Salesforce, Visualforce is defined by its documentation. The documentation for Visualforce is literally the specification for Visualforce. Anything that is not documented is simply undefined, even if you don't get a compilation error.

The documentation team has spent a lot of time documenting the bugs in the platform; many of the less dangerous ones are pointed out in the documentation (this is a relatively innocent, if not hair-pulling bug), and they omit the dangerous bugs completely hoping nobody finds them (I love finding these ones).

My advice to you is to brush up on the documentation. Everything you are allowed to do is in the documentation. Everything you are not allowed to do is not in the documentation. You can choose to ignore this advice at your own peril.

For the most part, Visualforce development has finished. It's as good as it's ever going to get. There are no new features coming out for it, just better Lightning compatibility to encourage us to move over. To fix this bug and a myriad of others, they would most likely need a major refactor or possibly a total rewrite, and it's simply not worth it with Lightning.

  • This doesn’t surprise me. The support case will, I’m sure, end up as WAD.
    – cropredy
    Commented Dec 27, 2018 at 3:31
  • @cropredy This bug has existed for at least 11 years... and this is a minor bug. I know of bugs that are far more aggravating than this one. At this this one is actually in the docs.
    – sfdcfox
    Commented Dec 27, 2018 at 3:33
  • 1
    Hmm. I didn’t see a doc ref for this. Must not have looked hard enough
    – cropredy
    Commented Dec 27, 2018 at 3:34
  • @cropredy Oh, you know, I just realized I was more focused on it not working for commandButton. Still, apex:param has always been temperamental. See this code: <apex:page ><apex:param name="test" value="123" assignTo="{!baz}" /></apex:page> No compile error or runtime error.
    – sfdcfox
    Commented Dec 27, 2018 at 3:40
  • @cropredy So, actually... this answer is wrong. Docs "If this attribute is used, getter and setter methods, or a property with get and set values, must be defined." That said, better log this as a documentation bug.
    – sfdcfox
    Commented Dec 27, 2018 at 3:44

From SFDC Support (after 30 days - case is now closed)

  • We acknowledge that there is no compile-time or runtime error when referencing non-existent controller property in apex:param tag inside VF page.
  • We have logged a user story to fix this behavior and support compile/run time error.
  • User Story will be reviewed and fixed in future release.
  • As of now there is no workaround to avoid this behavior and we don't create Known Issue link for a user story

So, that's it -- an indirect way of acknowledging WAD - Working As Designed. As @sfdcfox noted, VF is not going to get enhanced so the User Story may remain on the "backlog" in perpetuity. I filed a doc bug and maybe the doc will be updated.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .