Quote from: OpenGeek at Oct 13, 2008, 03:57 PM
Ok, we’re still misunderstanding each other clearly so let’s step back. I still insist using a chunk is a critical mistake that will mislead other developers into doing things this way right out of the gate. Use another snippet if you are going to do this and process it in the intended way. We’re still missing the point I think with this back and forth over configuration settings and element properties...
Ok (stepping back), I get your point that what I’m doing is a perversion of what chunks are for and I’ve come to agree that it would serve as a bad example and I shouldn’t do it. As an interim solution, what if I put the code in a snippet instead? I could use runSnippet() instead of eval() if you think that would be a better option. Would the variables set in that snippet be available following the runSnippet() call?
Quote from: BobRay at Oct 13, 2008, 03:28 PM
I could also easily make the parameters in the snippet call override the ones in the chunk, but I’m not sure that would improve the experience for the user in any way.
The intention was for configuration settings (system, context, and user) to provide exactly the kinds of default values you are talking about, for multi-element components to share settings that could be overridden implicitly in the configuration, as well as explicitly through the element properties (or parameters). So I would say the snippet properties need to override the configuration settings which you can deliver from the package as system settings and/or context settings for each context it would apply to. This is the best practice I want to present to the developers, so please continue to help me get there, as you are doing.
Well, we’ve established that the default System Settings are generally read-only values for system-wide settings that will be available everywhere, so they’re no use to me -- we presumably don’t want every default parameter for every snippet crapping up the system settings table. It also seems like overkill to have every package operate in its own context and create System settings for its own use, though that would be a solution if it was easy to understand and do. At present, I don’t really understand what "context settings" actually are or how they work (unless they’re regular System Settings that only apply in that context). And, if I’m correct that they don’t apply across requests to files in another context, they don’t solve the problem in this particular case. Nor do $_SESSION variables help, for security reasons, in this case.
Specifically, what, besides making the default properties for a snippet an editable grid, do they need to be able to do? I think I have an idea how, without changing the format for them in the database, we can make them be editable the way we want, and even use lexicon keys as the short description to render in the interface. Would that convince you to use the combination of context settings and snippet properties to handle these configurations from system to element?
To answer that, I’d have to understand "context settings," which I don’t. There’s no "context" field in the System Settings grid and I don’t see any place in the Manager to set "context settings."
Actually, I’m not sure exactly what you mean when you say "snippet properties" either. I’ve been assuming that you mean those things that are often set with the ternary operator in snippets;
$setting = isset($param1)? $param1 : 'default value';
But it’s not clear to me if you consider the things set via parameters in the snippet call to be "snippet properties" or not, so this may be part of our miscommunication.
My primary goal, in this particular case, is to let the snippet user control the behavior of the snippet without using any parameters in the snippet call. In the case of SPForm, having them in a grid might be fine, since the package is likely to be used just once per web site. With things like Ditto or Wayfinder, though, the user would need to control each instance of the snippet and I’m not sure how that would be accomplished unless the parameters in the snippet call would override those in the grid.
Let me include the code I currently have in the config chunk so you can have a clearer picture of what I’m doing. The variables that start with an underscore,
[email protected], and
[email protected] are replaced the first time the snippet runs with the appropriate values.
/* SPForm Config File
Snippet: SPForm
Version: 3.0.2
$Revision: 162 $
$Author: Bob Ray $
$Date: 2008-10-12 16:59:02 -0500 (Sun, 12 Oct 2008) $
Adapted from: Many sources but particularly scform by James Seymour and CFFormProtect by Jake Munson
Compatibility: MODX Revolution
*/
/* Note to users:
*
* You control the behavior of SPForm by editing this
* file. The comments in the file will tell you what
* each option does.
*
* Even a minor error in this config will keep SPForm
* from working. Edit carefully.
*
* Any line that starts with a
* variable name ($variable) should have one of the
* following forms:
*
* $spfconfig['variable'] = true;
* $spfconfig['variable'] = false;
* $spfconfig['variable'] = "value";
* $spfconfig['variable'] = 'value';
*
* When editing, be careful to match quote types,
* have an even number of quotes, and finish the line
* with a semicolon.
*
* When you change other lines, be sure to leave things
* in exactly the same format you found them.
*/
/* this array holds all config data */
$spfconfig = array();
$spfconfig['spformPath'] = MODX_ASSETS_PATH . "snippets/spform/";
$spfconfig['spformURL'] = MODX_ASSETS_URL . "snippets/spform/";
$spfconfig['test_mode'] = false;
$spfconfig['spfDebug'] = false;
/* Contact Form configuration
***********************************************************
Things you should check before using the snippet
***********************************************************/
/* SPForm will try to set these variables automatically
* when the form is first visited. Preview the form in your
* browser and, if the from doesn't work properly, look here */
/* $formProAllowedReferers
* This is used by the form processor, not the form. Allowed referers are
* domains/IPs you will allow this processor to be "called" from. You
* probably want this to be, for example, the hostname of the host your
* form page is on. If this is empty, *any* host can post to this script.
* Then again: The HTTP REFERER is easily faked, and some firewalls and
* HTTP proxies delete it, anyway. (See $formProcBlankRefOkay, above.) To
* allow any referer, use $spfconfig['formProcAllowedReferers'] = array(); If you use
* $spfconfig['chkFormRefOwnServer'] = true; (set below), be sure you have all possible
* variants here (e.g. domain.com, www.domain.com).
*/
$spfconfig['formProcAllowedReferers'] = array(
'mysite.com'
);
/* The $recipientArray holds all the possible titles and email addresses
* of people who can receive email through the form. Each line needs
* three entries, the first is used in error messages if the email
* address is poorly formed, the second appears in a drop-down list
* on the form if there are multiple recipients, the third is the
* email address (can be multiple addresses separated by commas).
* here is an example of a multiple list. Notice that the first line
* has no email address so selecting it is an error (and spammers will
* often select it by default):
$spfconfig['recipientArray'] = array (
"Please choose a recipient: Please choose a recipient:",
"Webmaster: Webmaster: [email protected]",
"Sales: Sales: [email protected]",
"Support: Support: [email protected]"
);
* Be careful to make sure that each line has two colons (:),
* there are three entries for each actual recipient, there are
* exactly two quotation marks surrounding the line, and each line
* except the last is followed by a comma.
*
* The following single-line version is the default.
* replace it with the multiple-line version above if desired
* (edited to match your needs).
*/
$spfconfig['recipientArray'] = array (
"Webmaster: Webmaster: [email protected]"
);
/* The next two variables are the MODx resource IDs of the spformproc
* and spfresonse resources */
$spfconfig['spformProcID'] = "_spformprocid";
$spfconfig['spfResponseID'] = "_spfresponseid";
/* Where to email error reports */
$spfconfig['errorsTo'] = "[email protected]";
/*
* **************************************
* Settings you can change or leave alone
* *************************************** */
/*
By default, SPForm uses mail() to send mail. If you change the following
parameter to true, SPForm will use SMTP to send mail. To use SMTP, you must
set the port, host, username and password. The email account doesn't need
to be on the same host. You can use any account you have at any host.
*/
$spfconfig['spfUseSMTP'] = false;
if ($spfUseSMTP) {
$spfconfig['spfSMTP_Port'] = 587; /* default port for authenticated e-mail - many hosts now block port 25. */
$spfconfig['spfSMTP_Host'] = "yourhost.com";
$spfconfig['spfSMTP_UserName'] = "yourUserName";
$spfconfig['spfSMTP_Password'] = "yourPassword";
}
/*
* Use hidden form field (idea suggested by RThrash) If this is true, a
* "Last__Name" field will be added to your form and then hidden by the CSS
* styling, automatically injected by SPForm. If it's filled in (presumably
* by spammer autobots), nothing is sent. The "hidden" content is not really
* hidden, just not visible, so no worries about being penalized by Google.
* Visually challenged users of text-only browsers or audio browsers MAY see
* the input field and fill it (although the text warns them not to).
* It works like a charm.
*/
$spfconfig['useHiddenField'] = true;
/*
* If $spfconfig['useHiddenField'] = true and $spfconfig['warnHiddenField'] = true,
* the user will be told that they shouldn't have filled the field.
* If $spfconfig['useHiddenField'] = true and $spfconfig['warnHiddenField'] = false,
* the script will exit with no warning if the field is filled.
*/
$spfconfig['warnHiddenField'] = false;
/* log users who fill in the hidden field
* only applies if warn is false */
$spfconfig['logOnHidden'] = false;
/*
* The following three variables require javascript to be on. There is no
* warning here, the program just dies on the assumption that a form
* without keyboard or mouse use is submitted directly by a spammer. The
* first choice is recommended since some disabled users may be restricted
* to either a mouse or keyboard. Presumably, voice- or muscle-operated
* systems would simulate one or the other.
*
* For accessibility, it's recommended to use only the the combined
* $requireMouseOrKeyboard option. The other two settings are
* best used just for testing.
*/
$spfconfig['requireMouseOrKeyboard'] = false;
/* If the above is true, the next two are ignored */
$spfconfig['requireKeyboard'] = false;
$spfconfig['requireMouse'] = false;
/* Inform User of mouse and kb errors */
$spfconfig['warnMouseAndKeyboard'] = false;
/* Log attemps to submit with no mouse or kb (only if one of the above is true)*/
$spfconfig['logMouseAndKeyboardErrors'] = true;
/*
* if $spfconfig['useTimer'] = true, the user will be timed filling out the
* contact form. taking too much or too little time will be an error. max and
* min variables are in seconds. Note: A user who violates time or any other
* check will press back to get to the form but their time won't be reset
* unless they reload the form page. They are warned to do this on a timer
* violation if $warnTimer=true, but if they make enough errors to get over
* the time limit they'll have to re-load the page and lose their work.
* That's why the default max is 30 minutes.
*/
$spfconfig['useTimer'] = false;
$spfconfig['useTimerMin'] = 10;
$spfconfig['useTimerMax'] = 30 * 60;
/* Warn users of timer violations. If on, the user is warned to go back
* and reload the form page to reset the timer (otherwise, the elapsed
* time will keep getting longer and longer). If you set this to false,
* you might want to raise $useTimerMax. */
$spfconfig['warnTimer'] = true;
/* Obfuscate timer value */
$spfconfig['timerOffset'] = 14543;
/* Log timer violations if $spfconfig['useTimer'] = true */
$spfconfig['logOnTimer'] = true;
/*
* Add distinctive prefix to "Subject:" in "[]" field? The "distinctive
* prefix" will be the sole contents of the "Subject:" line, less the "[]",
* if $requireSubj is false and there's no Subject. */
$spfconfig['addSubjSig'] = true;
/*
* Default "Subject:" line or "distinctive prefix" if $addSubjSig is true
* and there's a subject provided, the subject line will have [your prefix]
* followed by user's subject.
* Example: $spfconfig['dfltSubj'] = "Sent from My Web Site";
*/
$spfconfig['dfltSubj'] = $_SERVER['SERVER_NAME'] . " contact";
/*
* Keep spammers from pasting too many links into your form and sending it
* (counts "http" instances); If people normally send you lots of links
* in one message, you'll want to change this.
*/
$spfconfig['maxLinks'] = 3;
/* Maximum length of recipient (make sure it's long enough for all your recipient's email addresses) */
$spfconfig['maxRecipientLen'] = 65;
/* Maximum subject field length */
$spfconfig['maxSubjectLen'] = 100;
/* All emails sent will be cc'd to this email address */
$spfconfig['mailAlso'] = "";
/*
* Which form fields are optional. It is assumed that nobody would want
* comments to be optional.
*/
$spfconfig['requireName'] = true;
$spfconfig['requireSubj'] = true;
$spfconfig['requireEmail'] = true;
/* size of the message window */
$spfconfig['spTextRows'] = 10;
$spfconfig['spTextCols'] = 50;
/* Include a button that empties all fields in the form so the user
* can start over (the sottwell option) */
$spfconfig['spfIncludeResetButton'] = false;
/* Show To: message in the form if there's only one recipient */
$spfconfig['spShowSingleRecipientTo'] = false;
/*
* $requireVerify is set to false, by default, for maximum portability.
* Servers need the GD library and Freetype enabled for this to
* work. Also, it's cumbersome for users and sometimes impossible for users
* with disabilities. With so many other protections in SPForm, it may not
* be necessary.
*
* NOTE: If $spfconfig['requireVerify'] = true, and the modx system setting
* captcha_use_mathsting is set, the user will be asked to solve
* a simple math equation. Useful now since regular CAPTCHA can be read by bots.
*/
$spfconfig['requireVerify'] = false;
/* Warn violators that they've entered the wrong code */
$spfconfig['warnVerify'] = true;
/*
* Info to optionally add to emailed form. Set to true for each you want.
* Will be stashed in X-Headers.
*/
$spfconfig['reportRemoteHost'] = true;
$spfconfig['reportRemoteUser'] = true;
$spfconfig['reportRemoteAddr'] = true;
$spfconfig['reportRemoteIdent'] = true;
$spfconfig['reportOrigReferer'] = true;
/*
* The following are used by the form processor, not the form Some
* firewalls and HTTP proxy servers delete the HTTP REFERER. By setting the
* following to "true," victims behind such misguided systems will still be
* able to use your form.
*/
$spfconfig['formProcBlankRefOkay'] = true;
/* Tell $errorsTo recipient about invalid referer hits? */
$spfconfig['adviseOnReferer'] = false;
/* Log them */
$spfconfig['logOnReferer'] = false;
/* Tell 'em they're banned, or silently discard?
* You might want to change this after you have
* things working well for a while. */
$spfconfig['warnBanned'] = true;
/* Tell errorTo recipient about bad referer attempts */
$spfconfig['adviseOnBan'] = false;
/* Log them */
$spfconfig['logOnBan'] = false;
/* Tell errorsTo recipient about bad CAPTCHA attempts */
$spfconfig['adviseOnVerify'] = false;
/* Log them */
$spfconfig['logOnVerify'] = false;
/*
* The following variables are used by the form, not the form processor
* Check HTTP_REFERER for sanity before even offering the form? Web form
* spammers often have HTTP_REFERERS that are blank, the URL of the form
* itself, or something entirely made up. Note: Even with the next two set
* to false, spformproc will still check the referrer against the list of
* allowed referrers as long as $spfconfig['chkFormRefNotBlank'] = true;
*/
$spfconfig['chkFormRefNotSelf'] = false;
/*
* Insist that, if there's a referer, it's our own server? Note: This can
* cause trouble if you (or your host) rewrite the incoming URL by
* prepending www or stripping it, or through rewrites or redirection. The
* php REFERRER variable may not agree with MODx's idea of the referer.
* Some users may get an "invalid referrer" message when submitting. The
* problem will be intermittent because users can reach your site with
* various URLs.*/
$spfconfig['chkFormRefOwnServer'] = false;
/*
* Make sure not blank? Use $chkFormRefNotBlank with care, as some
* firewalls and HTTP proxies delete the REFERER
*/
$spfconfig['chkFormRefNotBlank'] = false;
/* The $banList contains a list of banned senders.
* These are compared to the email address specified in the
* form, the REMOTE_HOST and REMOTE_ADDR, depending on the format.
*
* Note that each line must be enclosed by exactly two quotation marks and
* all lines except the last must be followed by a comma.
* Here are some examples -- showing how it's done.
'.example.com' bans any REMOTE_HOST ending in ".example.com"
'host.example.com' bans Any REMOTE_HOST ending in "host.example.com"
'10.0.0.0' bans Exact REMOTE_ADDR IP address
'192.168' bans Any REMOTE_ADDR starting with "192.168"
'[email protected]' bans Specifically "[email protected]" in email address
'@example.com' bans Any user "@example.com" in email address (kind of)
*
*/
/* This is the real banList but it is commented out to speed up SPForm slightly
* If you need to ban someone, remove the comment tags and edit the list */
/* ***** remove these lines to activate banlist
$spfconfig['banList'] = array (
'0.0.0.0',
'[email protected]'
);
***** remove these lines to activate banlist */
MODX Staff
