Kreg Wallace

The images for the buttons and header displayed in the petition form are placed there with CSS. The paths to these images are calculated relative to the CSS file that requests them.

Since you copied the CSS styles from a file inside the plugin folder to a custom petition.css file inside your themes folder, the images aren’t being found at the location requested.

Try copying the image files out of the plugin folder into your theme folder and then make sure the image paths in your petition.css point to them.

For the Facebook and Twitter URLs, those are added via JavaScript when you click the buttons. You won’t see them in the status bar just by hovering over the links.

It’s difficult to be sure based on a screenshot, but it looks like you have a custom theme with the top margin on the input fields set to 10px or so. That’s pushing the labels away from the input boxes. You would do better to leave the top margin at 0 (zero) and use the bottom margin to add vertical spacing between the fields. I think the style adjustment you’re looking for would be this (note the margin line):

.dk-speakup-petition-wrap input, .dk-speakup-message {
	color: #444;
	font: 14px/1.4em Helvetica, Arial, sans-serif !important;
	margin: 0 0 16px 0;
	padding: 0 0 0 2px;
}

Thanks for posting this, @somethingelse. I thought I had that issue fully resolved in 1.7.1. Glad you were able to find a simple solution.

Thanks, Bas.

I was thinking of posting the solution here too. Looks like you’ve got it covered.

@drlogic,

The feature you’re looking for isn’t something that’s built in, but you can do something similar. If you have Confirm Signatures turned on, then a confirmation email will be sent to the signer when they submit the petition – and you can customize the confirmation email on the Settings page.

Alternately, just download the petition’s signatures as a CSV file and import it into a bulk mailer (like Campaign Monitor, MailChimp and the like) and send out a mail blast.

To change the widths of the first and last name input fields you would need to edit the with of .dk-speakup-half input. So, using:

.dk-speakup-half input { width: 200px; }

would probably work. .dk-speakup-half and .dk-speakup-full are wrappers that go around the input fields.

There’s not a built-in way to do this, but you could edit /includes/admin-signatures.php to get the results you want. Change the lines that read:

ORDER BY $db_signatures.id DESC LIMIT $query_start, $query_limit

to

ORDER BY $db_signatures.id ASC LIMIT $query_start, $query_limit

This changes the query results order from descending to ascending. You’ll need to change this in 4 places, at lines 46, 83, 142, and 168.

I’m working to reorganize the code so that this statement will only appear once rather than 4 times, but that update is not quite ready yet.

Ok, I’ll try to get a fix for that soon. I suppose the proper behavior would be to first check in the child theme directory get_stylesheet_directory_uri() and if that fails, then look in the parent theme directory get_bloginfo( 'template_directory' ). Are you creating a parent theme with a custom petition.css for the petitions form?

Good catch! I must have the input restrictions on that field set a little too tight. I’ll try to fix it for the next update.

@sharonejackson,

You can make the plugin wider by creating your own theme. The easiest way to do this is to open the plugin’s Settings page and select “No theme. I will style the petition form myself.” for your Petition Theme option. Then create a petition.css file and place it in your active theme’s folder. The petition will now use the CSS styles in this file to display the form.

You can copy the default CSS styles from /css/theme-standard.css and paste them into your custom petition.css to use as as starting point.

The petition was designed to be narrow so that your page or post’s content can flow around it. See the demo page for an example. This placement is achieved by floating the form to the right using the ‘alignright’ CSS style that should be built into your theme, like this:


<div class="alignright">
[emailpetition id="1"]
</div>


The emails sent out by this plugin are plain-text only.

Ok, I re-installed the plugin on your site and then re-created the petition as you had it before. Then I added it as a widget.

I was able to successfully sign the petition, receive the confirmation mail, and confirm my signature. This all seemed to go well on the first try. Maybe a re-install was all it needed. (Feel free to delete my signature if you like).

After making the petition, I realized I had forgotten to check if you had made modifications to the settings page. Sorry about that. Any custom settings you made are gone now. You should visit the Settings page to make sure things are set the way you want. I doubt the settings page stuff would effect the errors you saw before, but let me know if they crop up again.

Thanks swinggraphics,

I’ll take a look at this and try to target the site home page rather than the WordPress install location.

For the custom redirect URL, I imagine this is something you would want to set on a per petition basis rather than having one custom redirect URL that applies to all petitions. Or would a site-wide redirect for all petitions work?

HumbleScholar,

I just tried logging in as suggested and was able to create and edit petitions without any problems or error messages.

I did notice all the error messages on the petition you created earlier. You said that you were manually editing the database fields to get your petition working. This is probably what’s causing the current problem. If you manually set the address_fields column to blank or to anything other than a serialized array (will look like gibberish in database view), you will get these errors.

My suggestion is to create your petition again from scratch using the provided UI and things should work fine. You can just delete your old copy of the petition (as well as the two test petitions I made).

There’s a new update (now version 1.7) that hopefully will fix this. Sorry for the troubles so far.

I don’t think the issue has anything to do with MySQL or PHP versions. It’s just a matter of ensuring that the value in the address_fields database column is always the same data type (serialized array).