Comments (25)
A slightly more advanced solution would be to allow the contact form shortcode to include embedded content, with nested shortcodes that define the fields to be included on the form.
[bw_contact_form]
[bw_contact_field name=_telephone label="Telephone" type=telephone required=y]
[/bw_contact_form]
This is similar to the solution offered by Jetpack's Grunion contact form.
It's different from Contact Form 7, in which the content is loaded from a Contact form CPT and doesn't use shortcodes, although they look like them.
The [bw_contact_field shortcode]
could be similar to the [bw_field]
shortcode. It may use the same functions.
It should also be possible to implement the bw_contact_field shortcode as a block.
from oik.
Notes about other forms plugins
wpforms-lite stores the forms in a CPT called wpforms
in JSON format
ninja-forms are stored in custom tables prefixed nf3
( eg where WordPress prefix is wp_
: wp_nf3_forms
and wp_nf3_form_meta
)
nf3_form_meta
columns include label, key & type eg values: Name, name, textbox.
from oik.
Note: oik-user has some disabled logic that's similar to oik's contact form.
from oik.
At present the oik/contact-form
block block isn't producing any field values for the fields in the form.
from oik.
At present the oik/contact-form block block isn't producing any field values for the fields in the form.
This was because the [bw_contact_field]
shortcode wasn't registered when using the block. When re-implementing the Contact form block with embedded Contact field blocks it may make sense to rework the logic generates and expands [bw_contact_field]
shortcodes into direct calls to the implementing logic.
The downside of this is that the code will become less extensible since there'll be fewer action hooks invoked.
from oik.
Rather than having a fields attribute on the [bw_contact_form]
shortcode I've implemented the solution to use the embedded [bw_contact_field]
shortcode.
- The default fields are: name,email,subject, and message ( not text ).
- At present Message is a required field and is added to the form if not already specified.
Since the logic uses bw_form_field()
to display the fields in the form, the [bw_contact_field]
shortcode supports the following field types. The field type can be determined from the field name, which is determined from the field's Label.
Field type | Field name | Notes |
---|---|---|
text | name, subject | and any other field not specifically catered for |
telephone | telephone | |
textarea | message, text |
The syntax for the bw_contact_field shortcode allows positional parameters
Position | Attribute | Default |
---|---|---|
0 | label | field |
1 | type | Determined from the name. |
2 | name | Determined from the label. |
n/a | value | null |
n/a | placeholder | null |
n/a | required | y if the label contains an asterisk ( '*' ) |
Examples
[bw_contact_field "Name *"]
produces a required text field labelled Name *
[bw_contact_field Telephone]
produces a tel field labelled Telephone
Note: bw_form_field doesn't yet support <input type="tel"
from oik.
Having achieved a reasonable level of success with the shortcode solution I now want to implement the oik/contact-form
as a block that supports embedded blocks of the type oik/contact-field
.
- The
oik/contact-field
will only be insertable into theoik/contact-form
. - It may support several variations such as Name, Email, Subject and Message
- When the Contact Form block doesn't contain nested blocks then it will behave the same as the
[bw_contact_form]
.
from oik.
The challenge here would be to find out how to implement InnerBlocks and ServerSideRendering at the same time.
It appears other people have already tried this, quite a while ago.
In WordPress/gutenberg#10478 Fabienkaegy wrote
There is no way to pass the InnerBlocks html string to the block renderer Rest endpoint. Which is something that I believe would be very useful.
I suppose I'll have to look at how Jetpack's Contact form blocks work. I assume that there's no Server Side Rendering.
from oik.
I suppose I'll have to look at how Jetpack's Contact form blocks work.
Rather than use Server Side Rendering I'm going to emulate the form in the block editor.
I'm making some progress. The blocks are much faster than when using Server Side Rendering.
Notes:
- It's OK in the editor, but I need to determine how to render the inner blocks for the front end.
- I haven't yet implemented the different field types: Text, Email and Textarea
- or field length
- or required toggle.
- And the method Jetpack uses for editing the Label is quite nice as well.
Actually, in the Editor the <table>
tag is outwith a <div>
. Not sure what to do about that.
from oik.
Actually, in the Editor the
<table>
tag is outwith a<div>
. Not sure what to do about that.
In order to display the Contact form nicely in the block editor I had to replace the table formatting method with grid styling.
For the front end this meant changing the form field logic that calls bw_tablerow()
to use a new function bw_gridrow()
.
It also entailed changing the logic to produce the outer table to a div that'll have the CSS grid styling.
The default contact form is now expected to be a <div class="bw_grid">
.
It falls back to a <table/>
when the bobbforms shared library version is lower than 3.4.0
The PHPUnit tests for the contact form will now default to the grid format.
Because this change produces different HTML from before the oik version should be changed to v4.9.0
I don't think it's necessary to make it v5.0.0
from oik.
Now that I've developed the form to be styled as a grid I can try to introduce a checkbox field that gets a user to confirm they understand how the data they submit might be used.
from oik.
I've added the checkbox and written logic to ensure required fields are completed. It's now possible to remove the requirement for the Message field. It can either be present but not required or not even present.
This means you can give it a different label, such as Text.
The slight downside of this is that it won't be passed to Akismet for spam checking.
from oik.
The slight downside of this is that it won't be passed to Akismet for spam checking.
This could be resolved by adding some logic to retrieve any textarea
field as the message
to be passed to Akismet.
from oik.
Additional requirements
- Contact form - Allow definition of email recipient - consider copying logic from oik-user
- Contact form - check why oiku_email is revealed to the front end
- Contact field - Need to be able to show the syntax for the
[bw_contact_field]
shortcode - Contact field - consider swapping input field and label for checkbox.
from oik.
Contact field - consider swapping input field and label for checkbox.
.bw_contact_form .bw_grid {
display: grid;
gap: 10px;
grid-template-columns: 1fr 3fr;
}
The above styling for the bw_grid
class, attached to the div inside the form,is automatically enqueued for the oik/contact-form block but not for the [bw_contact_form]
shortcode.
- Consider providing block styles for the block. See https://developer.wordpress.org/block-editor/reference-guides/block-api/block-styles/
- Consider reworking the shortcode to continue to use the table format when there's no embedded content.
from oik.
Contact form - check why oiku_email is revealed to the front end
This was done a long time ago prior to oik v2.3.
I believe the code can be adjusted so that the hidden field isn't required.
from oik.
Contact field - Need to be able to show the syntax for the [bw_contact_field] shortcode
I've implemented support for Help and Syntax and generated the shortcode in oik-plugins. There was a problem with the example due to a missing function. Fixed by loading shortcodes/oik-contact-form.php
at the start of bw_contact_field()
from oik.
Contact form - Allow definition of email recipient - consider copying logic from oik-user
I've started adding some logic to set the default values for the email
and contact
attributes.
Challenges are:
- setting the defaults has to be done during block registration.
- when the user blanks out an attribute it should be unset - reverting to the default
Blanking attributes
When the user blanks out an attribute it should be unset - reverting to the default
eg
<!-- wp:oik/contact-form -->
rather than empty strings.
<!-- wp:oik/contact-form {"contact":"","email":""} -->
This can be achieved by the following code.
/**
* Reset fields to defaults if they're blanked out by the user.
*/
const { email, contact } = attributes;
if ( email=== undefined || email.trim() === '') {
const attributeSettings = wp.data.select('core/blocks').getBlockType('oik/contact-form').attributes;
props.setAttributes({email: attributeSettings.email.default});
}
if ( contact===undefined || contact.trim() === '' ) {
const attributeSettings = wp.data.select('core/blocks').getBlockType('oik/contact-form').attributes;
props.setAttributes({contact: attributeSettings.contact.default});
}
The logic should attempt to cater for the oik-user plugin, which obtains the user's email and name from the author of the current post. In the [bw_contact_form]
shortcode this can be specified by the user=
parameter
from oik.
Setting defaults
Notes about the original implementation for the [bw_contact_form]
shortcode.
- When oik-user is active the
[bw_contact_form]
shortcode supports auser=
parameter - This can be used to override the default user, which is otherwise obtained from the post_author of the current post.
- When oik-user is not active the values are obtained from oik options
- The
[bw_contact_form]
shortcode supports analt=
parameter ( value =0,1,2 ) with alt=0 being the default. - See
bw_get_option_arr()
for the code and documentation.
Setting the defaults for the oik/contact-form
block has to be done during block registration.
- by hooking into the
block_type_metadata
filter we change the values defined inblock.json
- For the
oik/contact-form
block we can set default values foremail
andcontact
. - This only needs to be done when the block may be used in the editor.
- Block registration occurs before the post is loaded
- We can't use the same logic as for the shortcode since this relied on
$GLOBALS['post']
being set. - In its place I've written
oik_maybe_get_current_post_author()
- If it returns a user ID then the user's
email
anddisplay_name
fields are returned - Otherwise, the default values are obtained from bw_options, using the original functions.
The code needs to be tested when the block is used in the Site and Template editor.
function oik_maybe_get_current_post_author() {
$id = null;
if ( function_exists( 'oiku_loaded')) {
$post = bw_array_get($_REQUEST, "post", null);
$action = bw_array_get($_REQUEST, "action", null);
if ('edit' === $action && $post) {
$post = get_post($post);
bw_trace2($post);
if ($post) {
$id = $post->post_author;
}
}
}
return $id;
}
from oik.
Contact field - consider swapping input field and label for checkbox.
Q. Can this be implemented using block styles for the Contact field?
See #207 (comment)
A. Yes. I've implemented 3 different styles.
Now I'm wondering what other CSS and/or HTML tags I need for the front end styling to appear consistent.
from oik.
Local tests for these blocks are currently in 5 posts in cwiccer.local eg
https://cwiccer.local/wp-admin/post.php?post=3751&action=edit
from oik.
Related Issues (20)
- oik/address block - wrong description in block.json HOT 1
- Add support for lazy loading images `loading="lazy"` HOT 2
- Change bw_follow_me to support `font=svg` to replace `font=dashicons` or `font=genericons` HOT 7
- Google Maps block doesn't work in blocks.wp-a2z.org HOT 4
- bw_table excerpt field processing doesn't render blocks HOT 1
- Unexpected JavaScript shown in snippet for the [bw_power] shortcode
- [bw_wpadmin] not wrapped in any div/span tag so gets flowed inline
- wp-pompey.org.uk - Fatal error: Uncaught Error: Class 'OIK_SVG_icons' not found HOT 2
- oik/shortcodes block - SelectControl is enormous HOT 3
- Shortcodes not expanded in `term_description` HOT 5
- Default `show_in_nav_menus` to false if not set HOT 1
- Warning on oik options > plugins Add new HOT 1
- bw_get_posts() - Add support for post_name attr HOT 2
- [bw_pages] - dynamic blocks not being rendered HOT 1
- Update to the latest @wordpress/scripts package and rework as required HOT 5
- Warning: Invalid DOM property `fill-rule`. Did you mean `fillRule` ? HOT 2
- Blocks not registered in oik downloaded from WordPress.org HOT 1
- Memory exhausted while running PHPUnit tests for oik on s.b/wordpress HOT 1
- Consider making [bw_accordion] front end more accessible HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oik.