Does anyone know how to create a form block in
Developer Mode in Squarespace? I want to create a form with a Squarespace id and built in javascript validation and submit behavior but can't use the GUI since I'm in Developer Mode. I haven't been able to find any documentation on it so far. Any help would be appreciatated!
Developer Mode only gives you access to the overall site template itself, but does not give you access to you at the "block level". It does, however, give you access at the "block field level".
To add a Squarespace Form Block in Developer Mode, you'd add a Squarespace Block Field. Then, you must push your changes to the live site. Having done that, you can log into the live site and add Blocks to the Block Field as needed using the GUI. In your case, that may be adding just a single Form Block.
The other alternative is, of course, to add your own form code outside of the GUI, using your own HTML, CSS, and JavaScript. I'm guessing that is not what you're looking to do here, though.
With Block Field IDs, keep in mind that you can assign it a static ID which would allow you to reuse it across any page on the site. Or you can assign it an ID based on the Collection ID, therefore making the Block Field unique on every page that loads the Block Field.
Related
As you may know, Chrome does not support:autocomplete="off", autocomplete="nope", autocomplete="false" or even autocomplete="new-password" any longer.
That means, from time to time, I do get reports that honeypot traps are preventing users from submitting forms, since the trap input is being auto-filled, even if not shown.
The practice for setting the trap is wrapping a TEXT input with a display:none; element, so spam bots won't be able to figure its really hidden (unless they are smarter and they usually aren't), and if this input has contents, you won't allow the submission to go through, as the field supposed to be hidden and empty for regular users.
What's your practice in using honeypot traps while still having browsers ignoring the demand for auto-complete or auto-fill by using the above arributes?
My current solution (October 2022) for a honeypot field looks like this:
Move the input field out of the visible area using css
Avoid name attributes that Chrome looks for when autofilling, like email, address, etc.
Do not wrap the honeypot input element with other elements that contain such keywords in their label or in name attribute
If you are using FormFind (which analyzes a page's source code and extracts the 'action' parameter and the input tags will find hidden fields. Hidden fields will not stop a spambot.
FormFind will find all the fields on a form from the HTML source code. And once you find the input fields - and the 'action' parameter (which FormFind does find) - its easy to use CURL or WGET to 'submit' the form.
Although reCAPTCHA will help with spambots, the only technique that I have found (and what I use in my solution) is to have some JavaScript code that will change the form's action parameter on a onclick/onfocus event. And if you put a delay in the JS function that changes the action parameter, that's a bonus spambot blocker.
Using JS to change things (or even to fill in a hidden field, if you insist on using one) is a good technique. CUSL and WGET cannot process JS code. (There was an open source project that claimed to be able to process JS code, but it was abandoned a couple of years ago.)
The JS trick is what I use in my contact form at my free FormSpammerTrap.com site. Code is free and open source. And the contact form there uses my technique. Have not gotten any spam via a spambot (automated process) from there. And I am working on a newer version that will add delays to even further block spammers.
Anyone is welcome to request the code to try it out. No charge. No fees. No advertising. No $$ benefit to me, other than how I use it on my sites to block spam.
So, using hidden fields to stop spambots is not going to work well. You have to have more layers of defense against them. Using JS code techniques is another layer that will help block almost all spambots. (There's no 100% solution, but I think mine is close - and it's been around for a couple of years.)
I removed the name variable from the input tag and this resolved the issue of the hidden honey pot fields getting autofilled...
What could be the reason why the Content Editor Toolbar of ADX Portal is not displaying, We recently published our code but then the editor toolbar is not displaying, we reverted our codes to the previous one but the same issue still occurs, while inspecting the html element the class "yui-panel-container" is there but the visibility is hidden, we change the visibility of it to visible but still there's no content.
What should be done to fix this issue?
Thanks.
If you are having the issue even after reverting your code, it makes me believe your web page access rules were changed.You must change permissions to grant on the page you want the content editor to show up.
In Administrator Web Role, make sure the target contacts are included.
Also, make sure Grant Change to Administrators is included in Web Page Access Control Rules.
Finally, in Grant Change to Administrators, make sure all required fields are filled in.
hi associate a web role to the user and then if you have created any business flow for your form in CRM , make sure to remove it and try again.
On my website I want to link to a web-app, automatically inserting some text into a textarea.
Is it possible to link to the website doing something like this?
www.website.com/#document.getElementById('textarea').value ='inserted text';
This bookmarklet is working code, I just want to use a link to the website and somehow get it to run the bookmarklet automatically.
javascript:{document.getElementById('textarea').value = 'inserted text'; void(0)}
Any suggestions/ideas?
On my website I want to link to a web-app, automatically inserting some text into a textarea.
You cannot, unless that web-app provides a means for you to do so (for instance, passing information on a query string or otherwise as part of the URL). You can't create a link that runs JavaScript on the page after loading it, not without the page's cooperation.
On the off-chance that the target web-app is also under your control: You could, of course, add a feature to the web-app to do it. If so, be sure you just accept a value and don't allow executing arbitrary JavaScript code passed to you on the URL, that would be a Very Bad Idea unless the target page never shows anything user-specific (and probably even if it doesn't).
I'm looking to see if it's possible to block certain data in web parts from loading or showing for certain users?
I have a SharePoint page that was written in asp.net and JavaScript. What i have is a page that runs several queries and displays them as separate web parts. I would like to be able to block certain web parts that show financial information to only show for the managers group.
I am able to just hide the web part from showing at all but that isn't necessarily helpful.
any help at all would be greatly appreciated.
thank you!
I would create a hidden div that contains the users access level (or I guess you could use an array to hold / define unique users who should or shouldnt be able to to 'see' the parts)... then just write a function that reads the hidden field and based on the user who is viewing the page, show or hide the content based on the id of the web content element / part.
I would probably try to do this on the server side though before the content in question is sent to the dom.
good luck
A possible solution could be is to hide the webparts using audiences. Edit the page, edit the webpart, navigate to the properties, in the Advanced section you'll find something called "Target Audiences". Either use an existing audience (which you can create in the user profile service application) or enter a SharePoint group name (like the site members, of something alike 'managers'). Members of that group/audience will see the webpart then. Other users will not see the webpart.
Notice that this is not a security measurement. E.g. it's just preventing the rendering of the webpart, it's not preventing users from accessing the data if they know where it comes from.
Read more here: http://office.microsoft.com/en-us/sharepoint-server-help/target-content-to-specific-audiences-HA010169053.aspx
Input fields are usually associated to forms, but I would like to use them in a simple Javascript/HTML page. I don't need the form. I see no issue with my HTML page, but is there any danger or bad practice I am not aware of? I just don't want my page to bug down the road.
(Basically, a field in my page can be Javascript enabled or disabled according to values in other fields)
The only real problem is if you want your page to function for users who have JavaScript disabled - if the inputs are actually for user input then placing them outside a form means that you'd need to use JavaScript (presumably with Ajax) to do anything with the values, whereas form fields can be submitted without JavaScript. If your page isn't intended to be submitted to the server anyway then you're dependent on JavaScript for interaction. If you've taken that into account and it doesn't matter for your scenario then go ahead.
P.S. I should've mentioned that as far as HTML standards go it is perfectly valid to have input elements that aren't in forms.
You should be fine AFAIK. It's ok in the HTML 4.01 standards anyway
http://www.w3.org/TR/html401/interact/forms.html#form-controls
The elements used to create controls generally appear inside a FORM
element, but may also appear outside of a FORM element declaration
when they are used to build user interfaces. This is discussed in the
section on intrinsic events. Note that controls outside a form cannot
be successful controls.
You can use an HTML validator (here, or on many other sites) to check this sort of thing. If it shows up legal, which I think it should in this case, as Ted pointed out, then you are probably good.