barkeyo

reported issue in new version see here for reference

Assuming that you are using the “Tel” tag for that field, see here for reference.

hi,

the second piece of code is used to inject the info outputted from the form into the constructed email. You simply add the code to whichever field you think is relevant.

e.g. I have the following in my mail “From:” field

[first-name] [last-name] <[email]>

and this in my “Message body:” field

From: [title] [first-name] [last-name]
Phone: [phone]
Email: [email]

Interested In:
[checkbox]

Message:
[message]

Alternatively, you could set the field as text field by using the text tag. This means the field input doesn’t get validated, and you will simply be passed whatever was input, but it therefore doesn’t require you to modify your theme’s functions.php or your theme’s style.css to allow it to function correctly for the UK and look the same as other text or text area fields you may be using.

Thanks for the pointer biswajeet. Fixed mine too, but I’m not sure in the most efficient way. My new style.css edit looks like this –

.inner_main input[type=text]{width:95%;height:16px;padding:6px 10px 6px;margin:1px 0 10px;background-color:#f1f1f2;border:1px solid #fff;border-radius:4px;box-shadow:inset 0 1px 3px #ccc;color:#b6b6b6;text-shadow:1px 1px #fff;outline:0}
.inner_main input[type="email"]{width:95%;height:16px;padding:6px 10px 6px;margin:1px 0 10px;background-color:#f1f1f2;border:1px solid #fff;border-radius:4px;box-shadow:inset 0 1px 3px #ccc;color:#b6b6b6;text-shadow:1px 1px #fff;outline:0}

I’ve effectively repeated the entire style entry of the text input field, for a whole new entry addressing the “email” input field. Is it possible to actually merge the two, so I have both fields being handled by the one style line?

Thanks,

Owen

Hi,

Having the same problem here. Both the Tel No. and Email fields have changed style since the upgrade to 3.4 today. Previously the Phone Number field was a Text field, but in 3.4 it uses the the form Tag “Tel” and both that and the Email field gets validated. If I change the field tag for a phone number input back to text, I recover the form’s css styling for that field, but we lose any validation. I happy with that for the phone number, but not with email. So for the moment I’m stuck with an email field which visually doesn’t fit with the rest of the form.

Any help would be appreciated.

Thanks,

Owen

Hi Luca,

It’s a relief that you’ve found the bug, as I love the functionality of your plugin, however my own experience with it has highlighted one thing that would be really useful in random mode. If a user could actually be able to explicitly define the number of posts being used for the pool from which the selected number of displayed posts are picked.

i.e. if I chose 5 posts to be displayed, then rather than simply displaying the next 5 posts after any offset is taken into account, it would be great if I could define that those 5 posts should be picked at random from the next x number of posts.

Available settings would then be:
– Max number of posts to use (-1 for all posts)
– Offset from most recent to exclude
– Number of posts to display

This would mean that the list will always be fresh (rather just the same ones displayed in a random order) and helps bring attention to older posts too.

Once last thing, and just in case you weren’t aware, the plugin CSS defined in css-front.css is also being overridden on occasion by class-main.php. I found this when trying to change the H4 setting for the /* The single post title. */ in css-front.css. I eventually found that $srp_content .= $this->srp_create_tag('h4', $ptitlelink, $ptitle_heading_atts) in class-main.php renders the css edit useless.

@gormley, you’re using an offset of 5… and you are seeing the plugin use the next 10 as its pool of posts. Interesting, 5 + 10 = 15.

I’m guessing that if you set the offset to 10, the plugin will always display the exact same 5 (i.e. posts 11 thru 15), just in random order at evey page reload. My testing seems to indicate the pool it uses is a static 15 most recent posts, and all the offset does is effectively reduce the number of posts available to it from the pool.

Hi Luca,

Thanks for the response. I understand the implication of ‘Recent’ in terms of usage, but your plugin doesn’t appear to work that way either. On the basis of your comment, the following shortcode usage should simply pick the most recent 5 posts (default value) and simply display them in a random order –

[srp widget_title_hide=’yes’ post_random=’yes’ display_thumbnail=’no’ post_content_mode=’titleonly’ post_date=’no’]

However it is clearly selecting and displaying posts from a range beyond the most recent 5 (or 6 when excluding current one in single post view), but there does appear to be a cut-off point somewhere. From my fairly limited testing, I think the limit actually kicks in at Post 15, so you are actually picking and displaying 5 at random from the first 15.

You can see this at work on my websites homepage (prokinesis.co.uk) where I have a drop down list of all the posts in date order (most recent first), underneath which I then currently use SRP to display 5 with thumbnails in random order. As you’ll see, what your plugin displays doesn’t always correspond to the first 5 in the drop down list.

I’m using the shortcode implementation of SRP 1.9.8, and I have the same problem –

[srp widget_title_hide=’yes’ post_random=’yes’ display_thumbnail=’no’ post_content_mode=’titleonly’ post_date=’no’]

which in theory should default to a display of 5 posts selected at random from my entire post archive, barring the current one if in a single post view. However, yes it picks 5 posts to display, but always from what seems to be a very restricted number of more recent posts. I’ve only got around 80 odd posts, so would expect to see some of the older ones crop up in a truly random selection quite regularly, but they never do. I just seem to get the same ones from this ‘restricted’ number of posts cropping up far too regularly, even if they are listed in a random order.

BTW I’ve tried using the widget version of SRP, but it makes no difference as the result is the same.

I think therefore that the process of ‘randomly’ selecting posts from the database is nowhere near as random as it should be.

Hi Nick,

Installed 4.1 et voila, all works just fine, thanks. Love the plugin, simple and effective. The new features are really useful, especially alignment as it elminates the annoying workround I was having to use to get the map positioned right.