I've been using Gravity Forms with no problems for a while, but today I'm receiving this error reading the following:
There was an issue creating your form.
Here is a screenshot of what the error looks like.
When I click on the System Status button to get more information, I see that the Database section has a red x reading the following:
The database is currently being upgraded to version 2.4.14.4. Current Status: Error Migrating Entry Headers: Table 'local.wp_rg_lead' doesn't exist NAN% complete. Force the upgrade
Here is a screenshot of the error above:
I click on the Force the upgrade button, but it has no affect on the issue.
Would anyone have any experience in solving this issue with Gravity Forms for WordPress? Thanks a lot!
I faced simillar issue on one of my sites but after sometime i manage to
solve the issue by following steps.
Export gravity forms tables from database.
Export forms and entries from from wp admin
Drop tables of gravity forms from database.
Re activate/ install gravity forms in wp admin.
Import gravity forms and entries in wp admin.
Thats it problem is solved and now you can create new gravity forms without any issue.
Uninstall Gravity Forms via the plugin General Settings page (Settings > Uninstall)
Reactivate the plugin again via plugins page.
As of the time of this posting, GF does not drop tables on plugin reactivation or deletion via the plugins page.
Similarly it will not create the necessary tables on reactivation and even reinstallation after manual removal of problematic tables from the DB.
GF will only drop tables after uninstalling via the plugin settings, at which point GF will create the required tables again upon next activation or installation.
It's been this way for a long time now: https://legacy.forums.gravityhelp.com/topic/error-saving-form#post-70107
Related
First foremost: I am aware that this is not a general Typo3 bug/error per se, as I have working installations. I am hoping for hints/help in finding the error in this installation, as it's way too big to just set it up as a new installation.
I have an erronous Typo3 10.4.17 installation (updated to 10.4.x, no fresh install)
Problem: Edited elements in workspace are not shown in the Frontend preview (opened via "Show webpage" or other basic means in BE) nor in the BE View-module.
Additional info #1: They are however shown when preview links are generated via "Generate page preview links" and those are viewed.
Additional info #2: Changed elements only become visible after publishing them & clearing Cache
Additional info #3: Clearing any Cache does not make them visible in the preview
After comparing all settings I could think of to another working installation I decided to delve into the core in search for a hint/solution and got stuck there at following point:
TYPO3\CMS\Workspaces\Controller\PreviewController
Line 130 $workspaceItemsArray = $this->workspaceService->selectVersionsInWorkspace()
As well as:
TYPO3\CMS\Workspaces\Service\WorkspaceService
Line 220 public function selectVersionsInWorkspace()
At this point my edited workspace version of the element does get retrieved. selectVersionsInWorkspace() does get called when viewing the preview.
While the PreviewController does not further filter the staged elements, they are not displayed in the Preview.
I am looking for any hint as to where selectVersionsInWorkspace() might still be filtered or other hints as to possible reasons/solutions for this problem that I may have overlooked.
Just when I decided to post to SO a co-worker found the reason...
As it's a big installation we use a dev-domain as admins and each website (over 100) have their own domains which are also set as base in the Site-config.
Only when the preview is opened as either the base or a baseVariant the workspace-elements are displayed at all. In older version the elements would still be displayed when opened via other associated domains, just sometimes not 100% accurately.
Letting this stay in case anyone ever has a similar problem and is hopefully able to find this.
I am using PrestaShop 1.7.5.2 and recently changed my server & now the problem is that in my admin few pages are not working like "Products, Invoices, Stocks, Module Manager, Module Catalogue, Theme Catalogue etc.
My front end is working fine.
I have read almost all the content available but was not able to find exact solution to it.
Any help will be highly appreciated
Thanks,
GC
Edited just now by gauravchawla18 (see edit history)
Your database is incomplete. At least ps_translation table is missing.
Please check your database import.
This is a very peculiar problem. A client's Magento 2.2.6 EE has emptied its cms page table twice today (sometime between 5pm EST and 5:20pm and again between 11:00pm and 11:30pm). I have disabled magento's crontab until a solution presents itself. The action log also has no records of access.
I combed through the action logs but nothing there stood out.
Has anyone come across this before? And how would I debug this? The system is setup to make hourly db snapshots so it's just a headache at this point.
Way interesting. I would start logging your db calls to find when and how the tables are emptied.
Check out this StackOverflow answer using MySQL.
If you get the exact query and user info, if Magento system user, search your whole install for that query reference.
Another option, if you have Magento plugins, disable all and see if the issue presents itself again.
Does the index reset when the table is emptied? If so, try disable truncate permissions from the Magento user and see what error is thrown when this action is attempted again. This would be a way to find the source of the call using the Magento error log.
I am pretty new in Typo3 (I came from Joomla and WordPress) and reading the documentation I have some doubts related to the user manage the user in this CMS:
I am using Typo3 6.1.1 and reading here it seems to me that the user managment is quite different (maybe the documentation is related to an old version of the CMS?): http://docs.typo3.org/typo3cms/GettingStartedTutorial/EditAndCreatePagesAndContent/CreateUsersGroups/Index.html
In particular I am not understanding if in the 6.1.1 the backend user can ben divided in groups or if they simply are backend user because if I go into: ADMIN TOOLS ---> Backend User I can see the backend user but not the groups, why?
Tnx
Andrea
As you can see in mentioned doc, BE users can be divided by groups and easiest way for creating BE groups and next BE users is using WEB > List module.
Just using workflow showed at screen of this section you need to create records of both types (blue arrows) on the highest page (with id 0 - on screenshot it's called New TYPO3 site)
I'm not quite sure about the reason, but Backend User module doesn't allow to manage BE groups directly, however there's a tip (which is general for whole TYPO3) - you can create a BE group ad hoc - during the process of creating BE user by using additional icons in the form, take a look to screenshot below, the yellow pencil and black plus allows you to edit/create related records without canceling current edition.
I have developed a front-end system plugin for Joomla 3.0 which replaces keywords for HTML formatted objects. This works perfectly in my local lab environment but when installed on the hosted site (WHM/cPanel) it causes issues with the administration area and prevents the administrators from editing the articles.
When the administrator clicks on a article to edit the page attempts to load then appears to go back to the same page. I have developed this as a front-end plugin only so I shouldn't affect the administration area.
The problem is also preventing admin from creating anything new (news, blogs, content, menu items etc.)
As this does not happen within my lab I can only assume the issue is with some server settings which I may need to enable/disable. I have complete administrative access to both WHM, cPanel and Joomla so can change settings where ever needed...
Things I have observed:
The article URL changes from:
/administrator/index.php?option=com_content&view=article&layout=edit&id=7
to:
/administrator/index.php?option=com_content&view=article&layout=edit&id=7
when the plugin is enabled. Notice the ampersand has changed to amp;. This makes me think it could be something to do with UTF-8 character encoding has been set in MySQL to utf8general_ci.
Any pointers on configurations I may need to change would be greatly received.
Question: How do I prevent this from occurring (without removing my essential plugin).
If you create System Plugin that should work only on front-end you have to check in your plugin if current page is front-end. You can do it using this function: JFactory::getApplication()->isSite() or JFactory::getApplication()->isAdmin()
Example usage (I assume you use onAfterRender event):
function onAfterRender() {
// Exit if current page is from Administration panel
if( JFactory::getApplication()->isAdmin() ) return;
/* your plugin main code goes here*/
}
It will prevent your plugin from modifying administration panel output. If you already done it and it does check like it should to, there is no way that reason of your problems is that plugin.