How to disable Database Update Alerts in the Backend in Bolt 3.4.8 CMS - bolt-cms

Hello Community and Developers,
I have a problem in the backend of the Bolt 3.4.8 CMS. This is the new version.
Even if the database is being updated, the update message will always be visible in the backend. How can I disable it?
It annoys a bit that this message in pink color can be seen again and again.
Can I disable the message via the config.yml?
Thanks in advance.

There was a bug with some database upgrades where some changes were not correctly detected. This is supposed to be fixed in version 3.5.6 - so you should be able to get rid of that message by upgrading to a newer version of bolt: https://github.com/bolt/bolt/releases/tag/v3.5.6

It's can't disable via config.yml. I would not recommend disable it. Even if you disable this, you will not see suggestions for other updates when it's will need.
What fields does it offer you to update?
I had such a problem with the "User profiles" extension, the field "description". I did not find a solution, just deleted this field, because I did not use it.

Related

Unable to create a new project in Web2Project

I recently downloaded Web2Project after going through the reviews. Installation was a breeze and the application is neatly aligned. I was able to create the users, assign permissions, create companies etc.
However when I am trying to create a project , despite filling all the fields in the screen the page just refreshes back without giving any error message or creating a project.
I am looking to see if there is a way to troubleshoot what is going on with the page. I tried exploring to create an account in Web2Project support forums but not able to create an account through the available media and hence seeking technical assistance through Stackoverflow.
Web2Project New Installation
Web2Project Code (Just installed on WAMP Server) -- Projects Module
After filling all the fields in the Project Screen, the project should be created.
But the screen just refreshes without creating the project. No errors shown. When I go to Project List page nothing is created.
I was facing same problem. Took a lot of work until realized that the cause was the field PROJECT_ID of the table PROJECTS was not created with the auto increment definition. I just seted up this property and the problem was solved.
How did i discover the cause of the problem? In the SYSTEM ADMIN module, access the SYSTEM CONFIGURATION page, and then set the value of the field DEBUG LEVEL to 1, and check the field SHOW DEBUG MESSAGES. This will allow the web2project to log into C:\Windows\Temp\PHP72x64_errors.log (in case of my instalation) the error.
Good luck!
I'm facing the same problem and took a lot time to solved until I came here.
Goto the table project immediately, found no auto_increment in project_id field. Put it on, it worked!
And hoping current web2Project maintainer will fix this in their installer.
Thank you!

phpMyAdmin apparently ignoring POST data, no error

I am running MAMP on my OSX dev environment, and it recently notified me that it could auto-update phpMyAdmin to version 4.6.5.2. I did so, and all seemed to be well, I was able to browse my databases as before.
Soon I learned that some things weren't working. When I take actions that use a GET request, such as clicking the Browse tab on a database, it works. When I do anything requiring POST, such as a Search, or an SQL query, it ignores the request and reloads the page, no error message appears on-screen.
No errors or warnings appear in my MySQL, Apache, or PHP log files. The problem occurs on all databases, and it's only affecting phpMyAdmin--other locally hosted sites accept POST requests as normal. I am able to read and write to the databases though other channels (e.g., command line, PHP scripts, etc).
Has anyone else encountered this?
Does anyone have an idea what might be causing it?
I'm currently trying to roll back the version, but I need to figure out how.
I have encountered the same. It looks like I have resolved the problem by clearing cookies. Also switching between different auth_type(http, cookie, config) modes in config.inc.php could help.

Unable to Resolve Symbol on SQL code (PhpStorm issue)

I am using PhpStorm 2016.1.2 and have been comfortably using PhpStorm for a couple of years. I have my Storm set up with the Database connection and displaying the MySQL database that my PHP pages connect to. The SQL is usually written within the PHP page in custom functions via a database connection class.
An example code chunk:
$checkData = $dataBaseSecure->getSelect(
"SELECT check_login.fail_id, UNIX_TIMESTAMP(check_login.last_action) AS timer
FROM check_login WHERE check_login.ip_addr = ? AND check_login.check_drop = ? ",
$data, TRUE);
Don't worry about the database PHP wrapper, this style and layout of SQL in PHP has been around on my work for a couple of years, in PhpStorm and works completely and accurately on the server and on all testings.
As Of Yesterday (17th June 2016)
I don't know what's changed but suddenly PhpStorm is now telling me, on all my SQL strings, across all my Projects:
Unable to resolve symbol '<table name>'
or
Unable to resolve column '<column name>'
And also (due to this) PhpStorm no longer carries out any auto-complete or organisation functions as I work on my SQL code.
Solutions I've tried
I have already tried to invalidate and revalidate my caches based on this answer to a similar question. But that hasn't helped.
I have very carefully explored my settings but the PhpStorm Database tab successfully connects to the database, and as far as I'm aware I made no changes to cause this change in behaviour.
I have looked over the various (and many) settings in PhpStorm preferences but seen nothing that has shone any light on this issue, or the changes I have tweaked have not resolved it.
I have found this answer but this does not seem to apply as my table names are not variables. I have also found this post, which while dated 2014 shows a similar issue but not a suitable solution.
I only have one database connection in most projects, but the number of databases doesn't seem to effect if this issue occurs.
Fully escaping SQL queries with appropriate backticks around named entities does not resolve the issue.
I have correctly configured my SQL dialect to the correct MySQL.
Reading related posts I'm found on Stack Overflow has provided no useful information.
I have no plugins in PhpStorm that relate to this issue or PHP/MySQL interaction.
If you have any ideas how to resolve this please tell me. If you have specific preferences you'd like me to check please let me know and I can add them into the question, (there are so many preferences in PhpStorm I won't post them all here right now, as I'm sure most are not related to this issue).
The Key is that this system was working perfectly two days ago!!!
Please try re-synchronizing your DB schemas -- just in case if it somehow got corrupted or invalid.
If it did not give any visual results -- try more radical version of it:
close IDE
open .idea subfolder for this project (the place where this project settings are stored)
delete dataSources.ids file
re-open project in IDE
re-sync DB structure / re-create DB connection from scratch.
None of the above worked for me - what eventually did was...
Selecting a portion of the SQL string that would run and then right clicking and selecting "Execute" and selecting the schema.
For some reason that allowed PHPStorm (more like light
drizzle) to figure out what it should be looking at.

MySQL Cluster Auto-Installer

I am using MySQL Cluster Auto-Installer. I click the next button while keeping the default configurations. But finally when i click Deploy and start cluster it will give me the following error.
I cant find any information regarding this message in the web.
#dennypanther, It's always in the config dir such as: /usr/local/mysql/mysql-cluster/ and It´s called "ndb_49_cluster.log".
In addition, maybe you could find it within a folder named with the same node id, for example: /usr/local/mysql/mysql-cluster/49/.
It depends how you configure it in the installation process.
I guess you resolved this problem a long time ago, however I try to help you as much as posible.
This looks like a bug fixed in recent 7.5 release of MySQL Cluster.
I did the bug fix myself, there was an issue with
not handling Windows character set properly that
made the start of the management server fail.
Fixed by handling also Windows character set
in messages from OS. Don't recall exact version
it was fixed in, but definitely fix is in latest
7.5.

Losing data between updates (chrome packaged app)

I'm working on a chrome packaged app that saves a lot of data locally. I recently put it on the chrome store. To my dismay, whenever my user's chrome installation updated the app (v1.1.1 to v1.1.2 for example), all their local data was gone (indexeddb data). Why is this so?
Is it the expected behavior to wipe out all the databases on an update?
Is there any way to prevent this other than not pushing out updates?
(Also where can I report this issue/bug, if it is one?)
Update: filed a bug report, but now I can't reproduce the issue. Not sure if it was fixed or my situation was a fluke.
The documentation is fuzzy on this:
https://developer.chrome.com/trunk/apps/app_lifecycle.html
Preventing data loss
Users can uninstall your app at any time. When uninstalled, no executing code or private data is left behind. This can lead to data loss since the users may be uninstalling an app that has locally edited, unsynchronized data. You should stash data to prevent data loss.
I hope they will elaborate on this, because zapping user data on every upgrade is not a great user experience.
I put in an issue:
http://code.google.com/p/chromium/issues/detail?id=169417
one of the developers got back to me and said:
I can't remember the release numbers off the top of my head, but at
some point when we turned on correct partitioned storage, there would
have been one-time data loss. This was done before packaged apps
rolled out officially to stable. If the loss of data happened across
an chrome upgrade, then I would say it's expected. It certainly
shouldn't be happening anymore.