MickR

hi bcworkz,

Thought i’d drop back in and let you know how i got on.

In the end wrote a plugin to address the need. Plugin creates a new DB table on activation and I opted for a column based solution. Long and short of it is that for each new post 50 rows are automatically created. One of those is an auto-updated timestamp and i’m using that to roll round and update the oldest entry when the 51st unique visit takes place.

Plugin also has a shortcode function which displays the stats when called. (Avatar of person who visited, how many times they visited the post, the last time they visited, and a link to their profile).

In test mode and so far so good ??

Hi bcworkz,

You’re right, may be the way to go, and possibly using a cron job to do the tidying up.

One thing i’m not clear on though is whether you’re thinking add to the wp_postmeta table, or possibly creating a new table for the purpose.

If a new table, would you have any thoughts on the choice between one new table per user (post), versus one overall table where all visit stats are stored for every user.

If i’m storing 50 records for each user, a single global table could have anywhere from, let’s say, 500,000 records upwards. Whilst adding a record for each post view doesn’t have any real overhead, i’m wondering if retrieving the data (50 records spread across the table) for a user to see who has viewed their post could be processor heavy?

Obviously i’m still bouncing thoughts around here, but appreciate the feedback.

Hi t-p, thanks for the response. Had a look at that and it’s not really what i’m after. The difference being that that’s a simple count updating the same individual postmeta record each time a post is viewed.

What i’m trying to achieve is to store the IDs of the last 50 unique logged in users who view each post. The owner of a post will then be able to see which other registered users have visited their post. (In this particular application each registered user will only be allowed to create one post).

I’m bouncing between possibly using duplicate keys in the postmeta table, or alternatively creating/using a new DB table as a solution – if i could work out whether it’s possible to update the oldest of postmeta entries that have duplicate keys i’d be one happy chappy!

Hi rObbiem,

you might have got past this by now, but had a similar prob when trying out something similar here (update_post_meta not creating a new entry).

https://codex.www.ads-software.com/Function_Reference/add_post_meta provided an answer – basically use add and update in the same instruction and if the key doesn’t exist it will create one, eg:

<?php add_post_meta(id, ‘key’, $data, true) or update_post_meta(id, ‘key’, $data); ?>

(maybe try entering null data and see if it solves the prob?)

Hi TL,

Two possible thoughts…

1. Kreg has since updated the plugin after I applied the hack and I haven’t looked at the changes to his code since v2.1. It may be that you need to work through it to check that the changes still fit with the latest structure.

2. Also, did you change the database structure to capture the user choices: Using phpMyAdmin, I inserted n x new fields to the ‘wp_dk_speakup_signatures’ table.

Hi Daniel,

First off, I modified V2.1 of the plugin and Kreg released V2.2 a few days later. I’d imagine the relevant parts of the code haven’t changed too much, but if you’re using the latest version you’ll have to work through it and try and match up where the changes should be applied.

Also worth noting that any subsequent update of the plugin would probably need the changes reapplied, as they’d get overwritten by the ‘standard’ code.

Anyway here’s what I did:

1. Using phpMyAdmin, inserted 3 new fields (named as follows) to the ‘wp_dk_speakup_signatures’ table:
General
Presidential
Referendum

All configured as follows:
Type: varchar(1)
Collation: utf8_general_ci
(I positioned them just after ‘custom_message’ field).

2. Modified emailpetition.php and public.js which manages petition when used in page or post content.

3. Modified widget.php and widget.js which manages petition when used as a widget.

4. Modified class.signature.php which is used by both of the above to write to the database table.

Here’s some links to copies of the code as modified:

emailpetition.php
public.js
widget.php
widget.js
class.signature.php

Code should you appear when you click on each of those. Copy and paste into an editor (eg:PSPad) should make it easier to read. I’ve commented in where the hacks are.

Haven’t got round to modding csv.php yet, but browsing the database table via phpMyAdmin shows that the updates are going in just fine.

hope that helps,

Mick.

Tx for spotting that one – sorted ??

Hi Kreg,

No need to get back on this one – cracked it (widget.js)
As i’m only running one petition I made the permalink and posttitle variables permanent.

Cheers,

Mick.

Having just implemented the above have to say those tips certainly made the job easier. One thing I would add is that widget.php and widget.js also need similar changes if the petition is to be used in widget form.

Live example : diaspora.ie- democracy at work

Could probably make the ‘no checkboxes selected’ error message a bit slicker, but it works ??