projectnami
projectnami copied to clipboard
Gravity Forms Upgrade Error
Hello, I'm using Project Nami version 2.4.2 and had an older version of the Gravity Forms plugin. I recently decided to upgrade Gravity Forms to the latest version of 2.4.21. I kept running into some CREATE and ALTER permission issues, but finally was just able to download the new version and upload it as a "new" plugin. However, now I am getting the following system report:
Gravity Forms
Version: 2.4.21 ✔ Upload folder: C:\inetpub\wwwroot\projectnami-2.4.2/wp-content/uploads/gravity_forms/ Upload folder permissions: Writable ✔ Output CSS: Yes Output HTML5: No No-Conflict Mode: Yes Currency: USD Background updates: Yes Locale: en_US Registration: Site not registered ✘
Add-Ons
Advanced Post Creation: by Gravity Forms - 1.0-beta-7 ✔
Database
Database Version: ✘ The database is currently being upgraded to version 2.4.21. Current Status: Queued for upgrade. 0% complete. As this site doesn't support background tasks the upgrade process will take longer than usual and the status will change infrequently. wp_rg_form_view: ✔ wp_rg_form_meta: ✔ wp_rg_form: ✔ wp_gf_form_revisions: ✔ wp_gf_entry: ✔ wp_gf_entry_meta: ✔ wp_gf_entry_notes: ✔ wp_gf_draft_submissions: ✔ wp_gf_rest_api_keys: ✘ Table does not exist wp_gf_addon_feed: ✔
WordPress
Home URL: http://localhost/projectnami-2.4.2 Site URL: http://localhost/projectnami-2.4.2 WordPress Version: 5.4.2 ✔ WordPress Multisite: No WordPress Memory Limit: 40M WordPress Debug Mode: Yes WordPress Debug Log: No WordPress Script Debug Mode: No WordPress Cron: Yes WordPress Alternate Cron: No Background tasks: No ✘ cURL error 28: Operation timed out after 2001 milliseconds with 0 bytes received
Active Theme
Twenty Twenty Child: by Kelsey Gerchar - 1.0.0 ✔ Twenty Twenty (Parent): by the WordPress team (https://wordpress.org/) - 1.4 ✔
Active Plugins
Gravity PDF: by Gravity PDF - 5.3.2 ✔ Media List: by D. Relton - 1.3.1 ✔ Ultimate Addons for Gutenberg: by Brainstorm Force - 1.16.1 ✔
Web Server
Software: Microsoft-IIS/10.0 Port: 80 Document Root: C:\inetpub\wwwroot
PHP
Version: 7.1.29 ✘ Recommended: PHP 7.3 or higher. Memory Limit: 256M Maximum Execution Time: 300 Maximum File Upload Size: 30M Maximum File Uploads: 20 Maximum Post Size: 30M Maximum Input Variables: 1000 cURL Enabled: Yes (version 7.64.0) OpenSSL: OpenSSL 1.0.2r 26 Feb 2019 (268443951) Mcrypt Enabled: Yes Mbstring Enabled: Yes allow_url_fopen: Yes Loaded Extensions: Core, bcmath, calendar, ctype, date, filter, hash, iconv, json, mcrypt, SPL, pcre, readline, Reflection, session, standard, mysqlnd, tokenizer, zip, zlib, libxml, dom, PDO, openssl, SimpleXML, xml, wddx, xmlreader, xmlwriter, cgi-fcgi, mysqli, mbstring, gd, gettext, curl, exif, xmlrpc, Phar, soap, pdo_mysql, pdo_sqlite, imap, tidy, pdo_sqlsrv, sqlsrv
MySQL
Version: 14.0.1000.169 ✔ Database Character Set: Database Collation:
Date and Time
WordPress (Local) Timezone: UTC+0 MySQL (UTC): 2020-10-19 19:59:39.633 MySQL (Local): October 19, 2020 at 7:59 pm PHP (UTC): 2020-10-19 19:59:39 PHP (Local): October 19, 2020 at 7:59 pm
For the database error, I tried to run the forced upgrade with no luck. Does anyone have any suggestions to push this through and get my Gravity Forms working again?
I'm having exactly the same problem when trying to update :(
"Current database user does not have necessary permissions to create tables. Gravity Forms requires that the database user has CREATE and ALTER permissions. If you need assistance in changing database user permissions, contact your hosting provider."
I was going to uninstall GF but was afraid not being able to reinstall. Until we have a solution, maybe you can try to replicate the tables manually in your database with the help of the Documentation.
I didn't uninstall my older GF version when I added the new version plugin manually. Since there was a change to the tables with the new GF version, I now have the old tables "rg_..." and the new tables "gf_...".
There are 5 tables that have been flagged as "this object name already exists in the database". Do you think removing these and trying to force the upgrade again might help? Or would this be more of a redirect elsewhere?
Unfortunately table creation and modification will be a problem with PN for some time. For example, we still need to deal with the latest major update to Yoast which switched from Options to custom tables for data storage.
You're right. I'm having a 500 internal server error when using the new Yoast. Before it was just slow; now I can't even enter my front site. In the admin panel I can't enter the posts list until I disable Yoast :S. Disabling it is the only way I can see my frontsite again. Also the "SEO data optimization" button only drops a "Oops, something has gone wrong and we couldn't complete the optimization of your SEO data. Please click the button again to re-start the process." This is due to another 500 server error when the process starts.
I'm not sure @kgerchar. You should try it but remember to do a full site and database backup
@patrickebates, has this issue been resolved or is there a workaround in order to get Gravity Forms working?
I've only been able to update manually by uploading the plugin again, then it replaces the old one: but still the entries are inaccesible directly on WordPress
@patrickebates Hi Patrick, I would really love to be able to access the "Entries" information of every form.
Is currently unaccesible and is escalating to other issues like the MailChimp or Paypal plugins (The created feeds for this plugins are also unaccessible. They are correctly writing in the Database, just can't edit them in the FrontEnd and still don't know if they're working properly).
Could I help by becoming a Patreon supporter? I really work with this feature :S
Hey, not been ignoring this thread. Been focusing my limited availability of late on keeping Core updated. Need to finish reviewing the latest update this weekend. Always scares me when the initial merge of a major update doesn't generate errors right away in the testbed...
If you have any error logs related to query failures with this plugin (either from PHP or the translation log) feel free to post the details here. That's the fastest way to figure out a fix.
Always interested in supporters on Patreon, but not going to give you any false promises on issue resolution. Sometimes these things can't be fixed without modifying the plugin. Case in point, a few years ago Jetpack was convinced to add a switch/filter to force using a native call within WordPress rather than making the DB call directly in the plugin. That one change resolved almost all compatibility issues.
I'm really desperate because I bought the GravityForms plugin for this and some month's ago, the MailChimp plugin worked, but now none of them (PayPal or MailChimp) can display the feed. :(
And confirmed: the PayPal plugin not only doesn't display the feed, but cannot be enabled in the form when excecuted.
I searched for some kind of Log but unfortunately the GravityForms Log service doesn't capture any error. Digging more, I found my Database Audit Logs in Azure. Here's the issue I think:
<batch_information><failure_reason>Err 4145, Level 15, Server integriappsbd An expression of non-boolean type specified in a context where a condition is expected, near 'LIKEN'.</failure_reason></batch_information>
The statement was:
SELECT * FROM wp_gf_addon_feed WHERE addon_slug LIKEN'gravityformsppcp' AND form_id=26 ORDER BY feed_order, id ASC
I'm sharing also some screenshots to clarify more the Table structure and the data in it to see if it helps: https://integriappscom-my.sharepoint.com/:f:/g/personal/info_integriapps_com/EndCWO1DWIJBtMGaM-8EmesBIwL3lw1apvNpkMsBKIj2og?e=DHVCJt
I would really really appreciate any help with this :(
So there needs to be a space in there LIKE N
So far, I'm not finding anything in Core that would be causing that. Could that string be built in the plugin?
That could be. I'll try to find it in the plugin to see if is written like that... and try to correct it.
I'll give you the result as soon as I can find that line of code in the plugin (is weird to me if they have a mistake in the GravityForms side of that magnitude!)
I agree. Equally as likely that it isn't something in PN Core or it would have triggered something there as well.
We do have some places in there that had N added to queries for Unicode compatibility. I'm looking for those and other locations to see if there might be a connection.
You might also look for this line in /wp-includes/wp-db.php
$query = preg_replace( '/(?<!%)%s/', "N'%s'", $query ); // Quote the strings, avoiding escaped strings like %%s.
Try changing to $query = preg_replace( '/(?<!%)%s/', " N'%s'", $query ); // Quote the strings, avoiding escaped strings like %%s.
Looks like That's it
Pushed up so it will be part of the build this weekend. https://github.com/ProjectNami/projectnami/commit/388838a3b0bdd7380147817b575c6fbf0866a5e9
Man 😭 I can't believe how awesome you are for helping me. Tomorrow when I' again on my comouter I'll test what you told me. God bless you, really
@patrickebates That was the solution!!!!!!!
I can confirm that the change you made:
- Fixes the MailChimp plugin feeds display for Gravity Forms!
- Fixes the PayPal plugin feeds display for Gravity Forms!
Also, trying to go further, I found the error that may be causing that the GravityForms Entries are not being displayed:
<batch_information><failure_reason>Err 156, Level 15, Server integriappsbd Incorrect syntax near the keyword 'AS'.</failure_reason></batch_information>
And the Statement was:
SELECT * FROM wp_gf_entry AS t1 LEFT JOIN wp_gf_entry_meta AS m3 ON (m3.entry_id = t1.id AND m3.meta_key = N'status') LEFT JOIN wp_gf_entry_meta AS m4 ON (m4.entry_id = t1.id AND m4.meta_key = N'is_read') LEFT JOIN wp_gf_entry_meta AS c2 ON (c2.entry_id = t1.id AND c2.meta_key = N'id') WHERE ((m5.meta_key = N'form_id' AND m5.meta_value IN (14)) AND ((m3.meta_key = N'status' AND m3.meta_value = N'active') AND (NOT EXISTS(SELECT TOP 20 1 FROM wp_gf_entry_meta WHERE meta_key LIKE N'is_read' AND entry_id = t1.id) OR (m4.meta_key = N'is_read' AND m4.meta_value = N'')))) ORDER BY CAST(c2.meta_value, AS, DECIMAL(65, 6)) DESC