1. Author Posts | Subscribe Add this topic to your favorites (?)
  2. Author Posts
  3. August 30, 2012 at 4:45 pm #17913
  5. DaveLegassick
  6. Hi,
  8. I've received no reply in the other thread discussing this issue, but seeing as it drifted from the original question I thought it fair enough to start a specific thread for this.
  10. The other thread is here: http://wp-types.com/forums/topic/how-to-use-a-beta/
  12. As I outline in this thread Views is still causing conflicts with the Gravity Forms jQuery Date Picker and the one used in WordPress and available in the CPT view through the back end. The problem, as I detailed, is this:
  14. "With either version of Views installed (1.1.1 or 1.1.2b) the Gravity Forms date picker will not render correctly (the month and year drop downs appear with the next and previous arrows each side and a small rectangle to the right, no actual calendar) on the front end form but deactivating Views fixes this issue.
  16. The date picker on the custom post type edit screen in the WordPress admin renders incorrectly, just as described for the front end form, uninstalling Views has no effect on this.
  18. With Views 1.1.1 installed Gravity Forms with a date picker will not preview, generating the Java Script error I listed above, this is fixed in 1.1.2b and the preview works correctly and the date picker works in the preview."
  20. The Javascript error mentioned is this:
  22. "ReferenceError: wpv_calendar_image is not defined [http://localhost/wordpress/wp-content/plugins/wp-views/embedded/res/js/wpv-date-front-end-control.js?ver=1.1.1:24"
  24. Do the dev's have any thoughts on this? Using the latest beta hasn't helped, but could I perhaps enqueue or remove the specific scripts on loaded the forms as a temporary fix whilst you guys work on a long term solution?
  26. Any guidance would be much appreciated as this becoming the bane of my project at present.
  28. Apart from that loving everything you're offering!
  30. Thanks in advance.
  32. August 31, 2012 at 4:56 am #17938
  34. luoy
  35. Hi DaveLegassick,
  37. Thanks for your feedback, Please try our latest version of Views: 1.1.2, you can download here:
  38. http://wp-types.com/download/views/
  39. Let me know if there is still conflicts problem.
  41. Regards
  42. Luo
  44. August 31, 2012 at 9:15 am #17955
  46. DaveLegassick
  47. Just installed it and there's no change I'm afraid. In light of that any other ideas? As I mentioned above the preview function from Gravity Forms is working after moving to Views 1.1.2, and in case you're not aware this feature generates a demo of you form in an isolated environment from the rest of your site so it doesn't load any of the scripts or templates of the rest of the site and seeing as in 90% of cases Views would not be required when Gravity Forms is being used do you know which scripts we can prevent loading from Views (a code sample would be great) to try and prevent this from happening.
  49. Thanks for getting back to me,
  51. Dave.
  53. September 4, 2012 at 7:16 am #18126
  55. DaveLegassick
  56. Any updates on this? I've tried what you suggested and it hasn't worked, any suggestions?
  58. September 4, 2012 at 7:53 am #18130
  60. DaveLegassick
  61. Well I've got an update.
  63. I know a lot of people are having trouble with this and no one has had a proper answer that's managed to fix this so I can provide a big clue.
  65. *** Please note this information is a work around for the Views issue I have discussed above and does still not fix the Types back end issue although it is the same fault, see below for the Types fix ***
  67. The fault lies in a style not a script. I compared the working page source from a form preview and a not working live page and the sources revealed something interesting. The only difference between them with an relation to wp-views was the inclusion of the CSS files, and when you look at the error again with this in mind it makes a lot of sense, after all if it was a scripting error surely it wouldn't show at all not just badly. With this in mind I looked at the three CSS files included and these were:
  69. wpv-pagination.css
  70. datepicker.css
  71. wpv-views-sorting.css
  73. From this list it was fairly obvious that fault may well lie with the datepicker.css file so I did a search through the wp-views folder and found there is only one reference to this file. This is in <strong>wpv.class.php</strong> where it is enqueued on line <strong>112</strong>, commenting out this line fixes the problem.
  75. This returns me to my original question from this post that preventing or undoing this enqueueing fixes the problem. I'm aware this may only be a problem when other plugins are enqueueing a date picker before hand but I'm betting a lot of people do.
  77. *** Types ***
  79. The same is true of the date picker when used in the WordPress backend by Types, simply find the datepicker.css reference and commenting it fixes it. It's a little more complicated in Types but only due to the fact it's included via an array, simple comment lines <strong>75 – 79</strong> in the file <strong>date.php</strong> in the types folder and it works correctly.
  81. I'm hoping now someone has actually pinned the problem down the dev's can issue a simple fix, perhaps as simple as checking the page when rendered only enqueueing the file if no other plugin is enqueueing the date-picker.js script?
  83. Hope this helps people struggling with this issue.
  85. Looking forward to hearing from the dev's on this one.
  87. September 4, 2012 at 11:20 am #18147
  89. luoy
  90. Hi DaveLegassick,
  92. Since I don't have a copy of latest Gravity Forms copy, I can not duplicate the same problems in my localhost,
  93. But I have put it in our to-do list, let our developer check it,
  94. And could you invite Gravity Forms developer into this issue, this can help solve it more quick.
  96. Regards
  97. Luo
  99. September 4, 2012 at 2:23 pm #18160
  101. DaveLegassick
  102. I have posted a request in their forums here:
  104. http://www.gravityhelp.com/forums/topic/date-picker-conflict-with-wp-views-request
  106. Hope you guys can get this sorted out between yourselves as both plugins are amazing.
  108. I'll mark this topic as resolved as it can go no further for now and I have posted a work around for the mean time.
  110. Viewing 7 posts - 1 through 7 (of 7 total)
  111. This thread is marked as resolved. Support staff may not reply to more posts. If you need further assistance from our staff, please start a new thread.