Error when installing a plugin, last 4.7 dev

jpdupont · 2017-12-06 20:48:32

I try to install etc_datepicker, error : “Plugin not installed” +

User_Error "Unknown column 'textpack' in 'field list'"
in /home/rouvroy/webapps/rox/textpattern/lib/txplib_db.php at line 409.


adminErrorHandler()
textpattern/lib/txplib_db.php:409 trigger_error()
textpattern/lib/txplib_db.php:483 safe_query()
textpattern/vendors/Textpattern/Plugin/Plugin.php:100 safe_insert()
textpattern/include/txp_plugin.php:439 Textpattern\Plugin\Plugin->install()
textpattern/include/txp_plugin.php:50 plugin_install()
textpattern/index.php:232 include()

Bloke · 2017-12-06 22:43:04

Was this an installation or an upgrade? The column should have been created when doing either, I’m just curious where to look.

If upgrade, did you log out first?

Check your txp_plugin table and see if the textpack column is in there. If not, log out, set your prefs version string to 4.6.2 in phpMyAdmin, then log back in again.

jpdupont · 2017-12-07 08:46:54

It was an update. I think I have not made a logout before.
I have just done the required manipulations:
- Logout
- Check the absence of the textpack column
- Change the version to 4.6.2
- Login

After that, check in phpmyadmin:

The version has not changed (always 4.6.2)
The column has not been added
And in addition, impossible to activate the textarea where to paste the code of the plugin. I reported this problem yesterday to Philippe for Sand space , while yesterday I could paste something in Hive / textarea plugin, not in Sand space

Last edited by jpdupont (2017-12-07 09:22:17)

jpdupont · 2017-12-07 09:14:44

To be sure to work with the right files, I just:
- Logout
- Upload the latest github files
- Login.

I now have the following error when I log in on the “Diagnostics” page:

Notice "Undefined index: filename"
in /home/rouvroy/webapps/rox/textpattern/vendors/Textpattern/L10n/Lang.php at line 234.
textpattern / lib / txplib_misc.php: 1693 adminErrorHandler ()
textpattern / vendors / Textpattern / L10n / Lang.php: 234 updateErrorHandler ()
textpattern / update / _to_4.7.0.php: 42 Textpattern \ L10n \ Lang-> available ()
textpattern / update / _update.php: 91 include ()
textpattern / index.php: 198 include ()

Now the textpack column in txp_plugins is added. At refresh, no more error in diagnostic.
But the version has not changed (4.6.2) in phpmyadmin.
File upload stuff and plugin textarea not active.

Bloke · 2017-12-07 09:53:24

Seems like the upgrade script isn’t firing properly. That’s weird. I wonder if something changed very recently in that area that’s broken upgrades. Can’t think of anything that anyone’s done there.

EDIT: Hmm, I wonder if this has anything to do with it ? When you log in, you’re filling the $_POST array with login/pw info so that test will fail… right?

EDIT 2: Oh, wait, upgrade won’t alter the db version number, duh. It’s a dev version. So that bit is correct. But the fact other stuff is failing is a bit weird.

I’m baffled. Any clues, Oleg?

Last edited by Bloke (2017-12-07 09:57:16)

etc · 2017-12-07 10:06:52

Bloke wrote #308146:

EDIT: Hmm, I wonder if this has anything to do with it ? When you log in, you’re filling the $_POST array with login/pw info so that test will fail… right?

That’s possible, though the update script should then run on the next access… unless you do something special on login? Please try to axe this $_POST check, but perhaps leave async there, an update on article save is not a good idea.

Bloke · 2017-12-07 11:02:05

etc wrote #308147:

That’s possible, though the update script should then run on the next access

Yes, that’s what I’d expect. Although it might be better to run on first login.

unless you do something special on login?

Not that I’m aware of. The $_POST array is popualted with login and password and submitted like any regular form. In fact, if you log in, then immediately refresh, the browser offers to post the credentials a second time.

Please try to axe this $_POST check

Can do, but I still don’t see why this would prevent the update from running on second click somewhere else – at least in a dev environment. It does mean there’s the possibility of visiting somehere else first, and then be taken to the Diagnostics panel with the “welcome to Textpattern x.y.z” message showing. Which is a bit odd.

but perhaps leave async there, an update on article save is not a good idea.

Absolutely.

etc · 2017-12-07 11:47:46

Bloke wrote #308149:

Not that I’m aware of.
…
It does mean there’s the possibility of visiting somehere else first, and then be taken to the Diagnostics panel with the “welcome to Textpattern x.y.z” message showing. Which is a bit odd.

If update does nothing special on login, what if we don’t update automatically, but display a message like “A new version is available, please visit Diagnostics” and update there?

etc · 2017-12-07 12:13:01

Please test if this workflow solves the problem. Thanks!

Bloke · 2017-12-07 12:14:47

etc wrote #308151:

If update does nothing special on login, what if we don’t update automatically, but display a message like “A new version is available, please visit Diagnostics” and update there?

Two reasons:

You may have already uploaded the files via FTP and we can’t leave Txp in an “unknown” state until the DB changes are synchronized with what the file system expects. So the update needs to happen immediately on next page refresh/login.
Determining if a new version is available on each page refresh is (at least, was – might be better now we have a simple JSON file) expensive, even if we cache the results periodically. So the only check we do on every page reload is “does the version number in index.php match the one in the DB?” If not, it immediately triggers an update and bounces you to Diagnostics.

If we had an install process that didn’t rely on an out-of-band step (e.g. FTP) then we could probably do what you suggested. If we can overcome or sidestep write permissions issues, this might be possible, but that’s the primary reason we don’t auto-install config.php during setup (although I’ve often wondered we should try and, if it fails, ask them to do it by hand instead).

EDIT: also note there’s a difference between “new stable/beta version is available to download” (a check requiring external access to the JSON file) and “you have installed files from a new version, let’s go update the database too” (which just checks the index.php version number against the DB).

Last edited by Bloke (2017-12-07 12:18:56)

Bloke · 2017-12-07 12:20:52

etc wrote #308152:

Please test if this workflow solves the problem. Thanks!

Untested, but I suspect that will break people’s sites spectacularly ;-)

jpdupont · 2017-12-07 12:26:49

Bloke wrote #308154:

Untested, but I suspect that will break people’s sites spectacularly ;-)

I just uploaded the latest version. I totally emptied the cache of FFox, I reloaded every problem page with cmd-r
I had at the start the indication of a new version and sending to diagnostics.

My problems are still there: plugin upload: non active textarea and idem file upload zone.

BTW, site not breaken …

Textpattern CMS

Textpattern CMS support forum

#1 2017-12-06 20:48:32