Hi Thillion,
Thank you for your input. The date issue is weird as each server is different. The issue lies within the strtotime() function which converts dates to a unix time stamp. Most servers will prevent dates prior to 1970, but I have seen servers work with dates back to 1920, and 1901 as you mention. Unfortunately, I can’t predict how each server is set up- but can only provide some guidelines.
In regards to you stating that you are suspicious of the plugin – what exactly is it that you are suspicious of? The extension not working? I’m just unclear of what you mean.
Finally – 3 stars for a plugin that does what it’s supposed to, seems a bit harsh. If you had any sort of doubts or have any questions you can always reach out to me via the contact form on my site, and we can discuss. I am very responsive to and supportive of my users.
Thanks,
Evan
Dear Evan,
thank you for the quick reply. Maybe suspicous was the wrong word. Sorry, English ist not my native language. But my worries about the plugin are vanished, now that I know that the date-issue is different on each system. I always thought 1st Jan 1970 is the limit, no matter what. So, on our provider’s system 1901 is the limit. I thought if 1970 is always the limit, than the fact that “suddenly” 1901 is the limit, the plugin sometimes works this way or that way.
In this case with the historical addon the date-issue seems to be fixed. But before I can upgrade I need to clarify the budget for the plugin and the addon. It’s not my own site I’m working on.
Btw, charging $20 for the historical date addon suggests that it was very complicated to handle the date-issue. I don’t know the internal details of this plugin. In my basic understanding of php/mysql I thought that adding a simple date-field would do the trick.
Best regards,
Marcus
Hi Marcus,
The way the WordPress query works when pulling posts by date, is that it is expecting a unix timestamp value. Querying by a human readable date almost always results in some weird things happening or results in invalid query results altogether. Working around this was tricky. We not only had to re-write the way the dates are stored, but also re-write how the date is displayed on the front end/dashboard, queried by WP_Query and so on – all while maintaining that the free and pro versions both still work properly (with and without the add-on installed).
While I agree that $20 may be a little higher, you are not only getting a product – you are getting continuous support and updates for the next year, as well as any custom code or pointers you need to tweak anything within the plugin itself. The initial plugin is rather large, and took a great deal of time to develop – and I have been supporting it for a little over 2 years now – which I’m sure you can imagine is not easy. Many of our users are using the add-on alongside the free plugin, so to continue to be sustainable (and to stay afloat) we had to help supplement the cost of development and maintenance., or else we wouldn’t be able to continue to develop and support our awesome products.
Thanks.
Evan
Hi Evan,
it seems like adding new features to wordpress isn’t as easy as adding something to a simple, self-made homepage. I also understand that charging for a service is nececary. Who likes to work for free?
One last question: will the plugin stop working after the first year expires? Or will there “just” be no more support after that? “Just” because I think that support and updates for something one didn’t code/write is essential.
Kind regards,
Marcus
Hi Marcus,
The plugin will continue to work moving forward, even after the license key has expired. There are no blocking functions built into the plugin or anything, you just won’t be able to receive remote updates and you won’t be able to submit priority support tickets. The plugin itself, however, will still work and there will be no noticeable changes on your site or in the dashboard other than the small ‘license expired’ message next to the license key field.
Thanks,
Evan
