Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#13 2009-10-23 21:23:24

maniqui
Member
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 3,070
Website

Re: soo_txp_obj: OOP library for plugin development

Hi jsoo,

I’m having an issue I hope I will be able to explain.

Short version: on one server (the production server), if soo_txp_obj is installed, I get a blank screen on Preferences tab. On a similar server (my local server), the thing works flawlessly.

Large version: I’m developing a site on my local server and I’m not installing the plugins directly on the database , but loading them from the plugin_cache_dir. This approach works, although from time to time, there are plugins that may raise an error because it seems that TXP loads them (from filesystem) in alphabetical order (differently to the way it loads them when installed on the database, that uses the Order column value).

When one of this error appears, the solution is to usually rename (using numbers, or whatever) the one that has to be loaded so it’s loaded at the very beginning.

This “issue” applies to soo_txp_obj + soo_multidoc. As a quick side note, it’s weird, because the error is triggered if the plugins keep their “original” name:
soo_multidoc_v1.0.b.2.php
soo_txp_obj_v1.0.b.4.php
But then, if I just rename “soo_txp_obj_v1.0.b.4.php” to “soo_txp_obj.php”, the error disappears, even if “soo_txp_obj.php” still comes after “soo_multidoc_v1.0.b.2.php” if sorted alphabetically.
Not sure why, but the same “workaround” also works with other plugins that work in tandem.
Anyway, this may or may not be related to the Preferences blank page.

Let’s go on: after renaming (on the filesystem) the plugin to “soo_txp_obj.php”, everything seems to work as expected on my local environment. The two plugins load from the filesystem, and no errors on the admin side.

But when I move this setup to the live server, I get the blank screen on Preferences.
Moving soo_txp_obj.php from the plugin cache dir fixes the issue (of course, I also have to remove soo_multidoc, precisely to avoid the error of Multidoc not finding txp_obj).

The only “workaround” I’ve found to this is installing soo_txp_obj on the database, and remove it from the filesystem. Not a big deal, I can live with that.

But I’m still very curious about why it works ok on my local server but I get the blank screen on the production server…

Thanks.


La música ideas portará y siempre continuará

TXP Builders – finely-crafted code, design and txp

Offline

#14 2009-10-24 01:02:19

jsoo
Plugin Author
From: NC, USA
Registered: 2004-11-15
Posts: 1,793
Website

Re: soo_txp_obj: OOP library for plugin development

Juliàn, thanks for the very thorough description of the issues! As to the first, when you rename the plugin files, soo_multidoc won’t load soo_txp_obj when it calls it with require_plugin(). So this can be solved by putting soo_txp_obj first alphabetically, or by giving it the name that soo_multidoc expects, or by changing soo_multidoc’s require_plugin() statement to match the new filename.

The blank preferences screen I can’t even guess about just now, but I’ll give it some thought.

Edit: just a guess, but:

are you using (or have you ever installed) soo_plugin_pref (or its precursor)? I’m wondering if corrupted soo_multidoc preferences could be involved in the blank screen issue.

Last edited by jsoo (2009-10-24 01:17:36)


Code is topiary

Offline

#15 2009-10-24 20:06:48

maniqui
Member
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 3,070
Website

Re: soo_txp_obj: OOP library for plugin development

Hi Jeff,
thanks for your reply.

jsoo wrote:

Juliàn, thanks for the very thorough description of the issues! As to the first, when you rename the plugin files, soo_multidoc won’t load soo_txp_obj when it calls it with require_plugin(). So this can be solved by putting soo_txp_obj first alphabetically, or by giving it the name that soo_multidoc expects, or by changing soo_multidoc’s require_plugin() statement to match the new filename.

Ah, thanks! That explains why a library-type plugin will work even if it comes alphabetically after the one that requires the library. Cool.

are you using (or have you ever installed) soo_plugin_pref (or its precursor)? I’m wondering if corrupted soo_multidoc preferences could be involved in the blank screen issue.

I’ve installed soo_plugin_pref before any other soo_ plugin, as you suggest at your site. But it’s working on local copy but not in remote (an exact copy of the local one, using the same database dump), unless I install soo_txp_obj directly to the database..

If you have any idea what could I test, please, let me know. Thanks.


La música ideas portará y siempre continuará

TXP Builders – finely-crafted code, design and txp

Offline

#16 2009-10-24 20:28:00

jsoo
Plugin Author
From: NC, USA
Registered: 2004-11-15
Posts: 1,793
Website

Re: soo_txp_obj: OOP library for plugin development

When you say Preferences tab do you mean Admin->Preferences or multidoc plugin preferences (i.e., clicking the Options link in the plugin list)? I’ve been assuming the former, but want to be sure we’re talking about the same thing.

Edit: also, what version of soo_plugin_pref?

Last edited by jsoo (2009-10-24 20:29:32)


Code is topiary

Offline

#17 2009-10-24 20:44:41

maniqui
Member
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 3,070
Website

Re: soo_txp_obj: OOP library for plugin development

Yes, Admin -> Preferences.
soo_plugin_pref: Version 0.2.2.


La música ideas portará y siempre continuará

TXP Builders – finely-crafted code, design and txp

Offline

#18 2009-10-24 21:11:47

jsoo
Plugin Author
From: NC, USA
Registered: 2004-11-15
Posts: 1,793
Website

Re: soo_txp_obj: OOP library for plugin development

Grasping at straws, perhaps, but could you post all the fields for your multidoc prefs on both sites. That is, the output from this query:

select * from txp_prefs where name like 'soo_multidoc%'

Code is topiary

Offline

#19 2009-10-24 22:13:50

maniqui
Member
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 3,070
Website

Re: soo_txp_obj: OOP library for plugin development

Hi Jeff,

on both sites it returns an empty set.
And I’ve a few more notes to share.

On remote server:

  • soo_txp_obj (installed on database) and soo_multidoc not installed => Admin -> Preferences renders fine
  • soo_txp_obj (installed on filesystem) and soo_multidoc not installed => Admin -> Preferences renders blank
  • soo_txp_obj (installed on database) and soo_multidoc installed (on filesystem) => Admin -> Preferences renders blank

So, soo_txp_obj on filesystem triggers the blank page. But blank page is also being triggered by soo_multidoc when soo_txp_obj is on the database.


La música ideas portará y siempre continuará

TXP Builders – finely-crafted code, design and txp

Offline

#20 2009-10-24 22:19:00

maniqui
Member
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 3,070
Website

Re: soo_txp_obj: OOP library for plugin development

BTW, I’m using the ied_plugin_composer to check which plugins are installed on the plugin cache dir and to generate the “hard-file” version of plugins installed on the database (which I remove after generating the “hard-file” version).

But it seems that ied_plugin_composer doesn’t show the “Options” link on soo_multidoc (and not sure if it would show or any other plugin that enables the “Options” link), the one that would appear on a database installation of the same plugin.

Edit: it doesn’t show the “Options” link even if follow this steps:

1) re-install soo_plugin_prefs (after removing soo_multidoc)
2) active it
3) install soo_multidoc
4) active it.

The “Options” link isn’t there.

Last edited by maniqui (2009-10-24 22:26:52)


La música ideas portará y siempre continuará

TXP Builders – finely-crafted code, design and txp

Offline

#21 2009-10-24 23:42:50

TheEric
Plugin Author
From: Colorado & Montana.
Registered: 2004-09-17
Posts: 568
Website

Re: soo_txp_obj: OOP library for plugin development

What’s the point in this OOP library again? Wasn’t it supposed to make everything easier, even if it were at the expense of plugin speed?

Last edited by TheEric (2009-10-24 23:43:14)

Offline

#22 2009-10-24 23:54:13

jsoo
Plugin Author
From: NC, USA
Registered: 2004-11-15
Posts: 1,793
Website

Re: soo_txp_obj: OOP library for plugin development

Just emailed you a request to send me those files (the versions generated by ied_plugin_composer). You could also download the source files from github and try those:

http://github.com/jsoo/Multidoc/blob/dev/soo_multidoc.php

http://github.com/jsoo/soo_txp_obj/blob/master/soo_txp_obj.php


Code is topiary

Offline

#23 2009-10-25 06:33:31

Gocom
Developer Emeritus
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

Re: soo_txp_obj: OOP library for plugin development

TheEric wrote:

What’s the point in this OOP library again? Wasn’t it supposed to make everything easier, even if it were at the expense of plugin speed?

Didn’t know that open source / freetime hobby needs a reason. If jsoo wants to develop and use thing called soo_txp_obj, then let him. Ok?

Offline

#24 2022-10-19 06:22:21

helsinkifrostbites
Member
From: Ystad, Sweden
Registered: 2007-11-16
Posts: 47
Website

Re: soo_txp_obj: OOP library for plugin development

My hosting provider just updated to PHP 8.0, and now I get this:

Fatal error: Uncaught Error: Class “soo_html_table_component” not found in myserverpath/textpattern/plugins/soo_txp_obj/soo_txp_obj.php:1394 Stack trace: #0 myserverpath/textpattern/lib/txplib_misc.php(1153): include_once() #1 myserverpath/textpattern/lib/txplib_misc.php(1175): load_plugin(‘soo_txp_obj’) #2 myserverpath/textpattern/plugins/soo_image/soo_image.php(3): require_plugin(‘soo_txp_obj’) #3 myserverpath/textpattern/lib/txplib_misc.php(1479): include(‘/customers/4/e/…’) #4 myserverpath/textpattern/index.php(210): load_plugins(1) #5 {main} thrown in myserverpath/textpattern/plugins/soo_txp_obj/soo_txp_obj.php on line 1394

I’ve been happily using soo_image and soo_txp_obj for all my image displaying needs for an absolute donkey’s. Is there a way to fix it for PHP 8.0, or must I change my ways?

Offline

Board footer

Powered by FluxBB