I'm working on a Squarespace website in developer mode where I can create the website with code.
In the file site.region, I noticed that I can insert a footer block using this code:
<squarespace:block-field id="footerBlocksMiddle" class="Footer-blocks Footer-blocks--middle sqs-alternate-block-style-container" columns="12" label="{localizedStrings.footerMiddleBlocks}" />
However, I haven't been able to figure out how to insert a form block preferably so that I can set it as email storage.
I tried <squarespace:block-form but that does not work.
The error looks like this on the squarespace configuration page:
"Something went wrong."
How do I write out this code?
What's actually going on in the footer code you mentioned, is that a block field is being inserted. Within that block field, you can add whatever blocks in whatever arrangement you like.
So to accomplish your goal, you'll insert a block field and then add only a form block to it. Then, in other places where you want that form block to appear, you add the block field (containing the form block) into the code.
As long as you use the same id, the same block field will be reused, allowing you to edit the form in whatever area you happen to be in, and changes will affect everywhere else the block field was placed.
<squarespace:block-field id="myFormOnlyBlockField" columns="1"/>
Place that where you want the form block to appear. Of course, initially, you have to add the form block to it and configure it. From then on, adding the code above throughout your site template will show the form, and changing any instance of the block will affect all instances.
Note that I've set 'columns' to '1' in the example above, figuring that you're just adding a single block so no need to have more columns. you could set it to something else and it'd work just as well. Also note that the areas where you add the block field might have a bit too much spacing/padding/margin around it, so you may need to CSS to adjust for that.
Alternatively, it is possible to execute JavaScript within a code block to make an AJAX/Fetch request to the page with the form block on it, and have that form block replace the code block within which the JavaScript is executed. Such an approach would work even without developer mode.
Related
I am a research student working on an access database where I have created a continuous form that is to be used in a sort of scrolling electronic health record format. The header includes information about the patient and the continuous form aspect is a series of patient visits. In the header, I have a few subforms, which populate based on linking on the patient_ID number which is posted in the header (generated by vba macro such that previously reviewed patients aren't revisited). These subforms seem to significantly lag such that they the results from the previous patient stick around going into the next one. The subforms contain user-selected pertinent data. Each form has its own table. They are linked primarily based on patient_ID.
I have tried:
macro on the header detail: on click, refresh. - seems to work, but not very elegant/intuitive
macro on the main form - same as above but on load, click, got focus, lost focus, open, activate -- none of them seem to do anything.
forced requery via vba (see below) on opening/etc of the form. Neither way has worked. Tried to run these on opening the header form.
Public Function RequeryMain()
Dim frmMain As Form
Set frm = Forms("FRM_continuous_reports_patient")
frm.Requery
End Function
Public Function RequeryHeader()
Dim frmHeader As SubForm
Set frmHeader = Forms("FRM_continuous_reports_patient").FRM_continuous_header_working
frmHeader.Requery
End Function
In the end, it is frustrating for users to have to click to clear the form for new entries. It works otherwise.
The end goal is for the form to open and have all the subforms load based on the newest patient_ID. This would likely have to involve a staggered load: (1) VBA script selects the next patient based on certain characteristics and passes the patient_ID to the main form; (2) load main continuous form based on patient_ID submitted to it; (3) load the header subforms and any pertinent data within (although should be blank for the first time these are seen); (4) on completion, back to (1).
From what I understand, this is already how it is working, however the subforms are loading too quickly? How can I fix this?
Hopefully someone can help explain how to remedy this/correct any misunderstandings I have about the mechanics of forms.
I know this will sound odd, but subforms actually load before parent form. Lag in subform display is not something I have encountered. Code should not be needed and likely will not correct. Must be something about the form/subform design, maybe their RecordSource. Would have to examine db to determine.
It is not necessary to create form objects in VBA just to requery. Is code behind the main form? Me.Requery will be enough for the main form. I always give subform container a name different from the object it holds, like ctrPatient. Then just Me.ctrPatient.Requery.
Why not put subforms in Detail section?
To answer your questions, and provide a condensed version of the logic referenced at: https://accessexperts.com/blog/2014/01/07/delay-loading-subforms-in-access/
is to:
In design view, set your subform SourceObject to "" (and save your form)
When you are ready to show the subform, just execute: Me..SourceObject = ""
When you are ready to navigate to the NEXT patient, clear the subform link: Me..SourceObject = ""
Now that should solve the issue of out of sync data between the main and sub.
You don't need to use the CASE statements, but they operate as if you had a bunch of "If" / "ElseIf" all nestled together -- except the CASE makes it easier to follow. It basically gets a value from a variable (i.e. Select Case MyVariable); then checks to see if it equals what you want (Case 1, Case 2, etc.), and if so, does whatever you code.
I have a number of form inputs inside an element as they are repeated in other forms, however it does not output the content of the element when i include it in a view. I can place "Die();" within the element and it will show everything up until that point including the inputs within the element. When checking the source code (without the "Die();") it seems to have disregarded everything within the element including formatting such as DIV's.
The only thing i can think is that cakephp does not like you setting a form in a view then including inputs to the form using elements, does any one know if this is the case, or know the actual reason why this is happening?
The answer is i'm an idiot and forgot to echo the element.... yeah.
When I submit my form I am getting an error from my cfinsert function because there is not a database column name "SEARCHFIELD". The problem is "SEARCHFIELD" is not an input in the form I am submitting.
Both forms have close and open tags so I am not sure why my search form input is being referenced in my main forms submission?
Any thoughts?
Two ways I can think of to avoid this, without seeing your actual code it is hard to guess where SEARCHFIELD is coming from. As some of the comments pointed out it would most likely be from a CFPARAM or the name of your submit button in the form.
The first way you could tackle this is the CFINSERT tag has an attribute named formfields where you can list off the columns you wish to insert with. You can see that here in this doc link:
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7c78.html
Another way you could do this is you could add code to remove SEARCHFIELD from the FORM scope prior to running the CFINSERT. Which would be as simple as:
<cfset StructDelete(FORM, "SEARCHFIELD") />
You could check to see if it exists and if so then delete it but the StructDelete() will run without issues even if the field does not exist.
I personally do not use CFINSERT/CFUPDATE and I know the default opinion in the community is not to. They do have some benefits though that often are overlooked in that they do parameterise the SQL and offer at least some safety from malicious people. Without knowing anything about what you are doing it is hard to say if using them is actually a shot in your foot in the long run or something just fine to be doing.
I call a jasper report through an independent URL through which I pass one of the input controls needed to run the report.
E.g. http:// localhost:8080/jasperserver/flow.html?_flowId=viewReportFlow&standAlone=true&reportUnit=xyz&ParentFolderUri=abcd&j_username=xyz&j_password=xyz¶meter1=value1& . . .
As you can see in the above independent URL, I pass the JasperServer username and password, reportUnit name and location and other mandatory parameters, along with the report input parameter, i.e., "parameter1" which can have a value like "value1".
I used a mandatory, read-only and visible input control for this input value. Its value would come from the independent URL, showed in the box but was read-only and hence could not be changed.
The report was working absolutely fine upto this point.
But the tragedy began when my client rejected this idea. He wanted a completely invisible input control to my report and the input value would be passed through the independent URL, just like illustrated above.
And then my client asked me to refer to this and made me work on cascading input controls.
Recently I added a cascading input control to this report. The input control type is a single select query, which utilizes two parameters that I pass to the report through the independent URL.
Now when the Jasper server responds to the independent URL with the input parameters, all the other static parameters work properly, except for the cascaded one.
When I click the select box of the cascaded input, I can see the desired options for a second, and then, it just goes empty while I'm viewing the select list.
But when I make the "Parameter1" input control visible, the cascading input control works!
And then I turn in invisible, the cascading input control turns into a beast that does things by itself and not listen to his master.
I am not able to understand why this is happening. Could anybody please provide me a solution to this?
I have found a temporary solution for this.
I made the "Parameter1" input control visible and read only.
Next, I used a stylesheet and defined a style rule that would affect that input control's display on the web page, making "display: none".
I passed the name of the stylesheet through the URL. So this stylesheet is used for the report.
Now, the "Parameter1" input control is invisible to the end user and my report still runs with no one knowing it's just a fix.
app\locale\en_US\template\email\sales\order_new.html is the file in question.
How would one go about editing {{var payment_html}} without affecting other sections of the site?
It seems like the section comes from: app\design\frontend\base\default\template\payment\info\default.phtml
Am I correct about this? But that file is used in other places on the site. Is that correct too?
I want to create a separate file, say default_email.phtml, style it separately, and have order_new.phtml include the new file instead.
I assume that I need to include my default_email.phtml file in layout\***.xml. Where would I do this?
The first thing I did was a search in the source code of Magento. Assuming the {{var payment_html}} is processed somewhere I searched on payment_html.
Several results are matching the search;
Mage_Sales_Model_Order
Mage_Sales_Model_Order_Creditmemo
Mage_Sales_Model_Order_Invoice
Mage_Sales_Model_Order_Shipment
So the information for that payment block has to be in there. I took Mage_Sales_Model_Order and checked the variable $paymentBlockHtml. This is pointed to further logic to fill the payment block by payment information. It's creating a block and it looks like this is not easy to extend/change/modify on the first look.
Yes, we can apply a template to the specific (payment) block type since there’s a block created, but we can’t easily check which block we want to load. Also the template is overruled in the construct of Mage_Payment_Block_Info
Let’s check the other way.
Let’s do something cool, why we don’t add a block to the email which contains the correct information but more important where it’s possible to make a switch to the correct case. Since template parser is used for parsing the variables and layout handles we could add the following on instead of the {{var payment_html}} block and retrieving that information in the block itself.
{{block type='core/template' template='email/templatename.phtml'}}
The above code is parsing the email/templatename.phtml into the email, which means that you could do anything in that template to show the correct data.
Before we can retrieve the payment data in this template we have to add the order argument with the order data. That’s quite simple;
{{block type='core/template' order=$order template='email/templatename.phtml'}}
In the template we can do $this->getOrder()->getPayment() to retrieve the payment information, or $this->getOrder->getPayment()->toHtml() or process the data in another way.
Bonus;
Another solution is working with layout handles and set the correct template and type in the layout.xml, below an example for the order items in the same email. It’s working the same as the block, but only with some settings in the layout xml.
{{layout handle="sales_email_order_items" order=$order}}
In /app/code/core/Mage/Sales/Model/Order.php there is a method called "sendNewOrderEmail". This is what you need to affect. You will find code simmilar to the following:
$mailTemplate->setDesignConfig(array('area'=>'frontend', 'store'=>$this->getStoreId()))
->sendTransactional(
$template,
Mage::getStoreConfig(self::XML_PATH_EMAIL_IDENTITY, $this->getStoreId()),
$recipient['email'],
$recipient['name'],
array(
'order' => $this,
'billing' => $this->getBillingAddress(),
'payment_html' => $paymentBlock->toHtml(), //Just change this line
)
);
You can see that this is where the "payment_html" data gets set. Just swap it out to what you want it to be.
I had the same issue. What I did to only change the email was add the following to the payment info class.
protected function _construct() {
parent::_construct();
$this->setTemplate('payment/info/{new template}.phtml');
}
Then create the template and the email will insert this template to the payment section if this payment method is used.
Hope that's helpful!