function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Error with Apex Page in installation: Unknown property 'zqu__Quote__cStandardController.Quote__c'

In porting to a managed package, we blocked and tackled a number of issues with prefixes, but there's one hurdle that we can't seem to get over. More specifically,

1. We added a namespace to our dev org (zqu)
2. We packaged up a managed beta and installed in a test org.
3. When we hit the page in our UI (ZuoraQuoteSubmit) in our test org, we got the error
"Unknown property 'zqu__Quote__cStandardController.Quote__c'
4. This page works in our unmanaged installs, and continues to work in our development org.

In looking a little closer, we noticed that the installation attempted to prepend our package prefix throughout our Apex Page. However, it seems to have done this selectively. For example, our dev code looks something like:

<apex:page standardController="Quote__c" title="Quote" sidebar="false" >

var _billtocontactID = "{!Quote__c.BillToContact__r.Id}"; 
var _soldtocontactID = "{!Quote__c.SoldToContact__r.Id}"; 
var _zuoraPaymentMethodID = null; 
var _zuoraPaymentMethod = "{!Quote__c.PaymentMethod__c}";

After installation, the page looks like this in the installed org:
<apex:page standardController="zqu__Quote__c" title="Quote" sidebar="false"> 
	var _billtocontactID = "{!Quote__c.BillToContact__r.Id}";
	var _soldtocontactID = "{!Quote__c.SoldToContact__r.Id}";	var _zuoraPaymentMethodID = null;	var _zuoraPaymentMethod = "{!zqu__Quote__c.zqu__PaymentMethod__c}";
It looks like the installation figured out how to add it to the standard controller (zqu_Quote__c) and one of our merge field references ({!zqu__Quote__c.zqu__PaymentMethod__c}). However, there are two references right in the middle that were not at all affected.

We tried to corrolate this to the types of fields in our Apex page, but it wasn't conclusive; some custom objects had the prefix, some did not. some custom fields had the prefix, some did not. (I've attached the before and after files, cut-and-paste from the SFDC web UI.)

I think we might be missing something, because we don't really understand how the zuora prefix is added. Maybe it's something simple we're missing.



This is a bug. I've been working with Salesforce for a few weeks to try to have it sorted out although in my case the problem I was having was slightly different. Log a case with them as that's the only way they'll get it sorted out.





Interesting. We're kind of stuck as well, given it's a managed package.


Did you have a work-around? Only thing I can think of is to give customers an Apex page to install manually, but that's hokey.




No workaround unless you change from a standardcontroller to a custom one :( Perhaps you could log a case and try to get hold of one of their people on the phone because it's quite a big bug.



Any update on this?  I am running into the same problem?

I just ran in to this problem and thanks to this post worked around it.


In my case it appears the prefixes were not getting substituted in URLFOR expressions that contained line breaks. I had put these in as the expressions were quite long.


Aside from the failure of the prefixing process, the real time stealer here is the lack of component name and line number in the error message. This post got me on the track of looking at the deployed page source to find the problem.