r3661 error when saving an new article

jpdupont · 2012-02-24 16:42:11

I just install the last subversion on a new site I’m building.

I get this error when I save a new article :

Fatal error:

Error: '' is not an integer

assert_int()
textpattern/include/txp_article.php:81 array_map()
textpattern/include/txp_article.php:63 article_post()
textpattern/index.php:145 include()

in /home/www/af64996ab62a6940a44b274b9082059d/web/textpattern/lib/txplib_misc.php on line 2398

No problem when saving previous articles.

I try on an other site just installed with r3661 and sed_cleaner : fresh new install, other hosting : same error, when saving a new article.

=======

I try to revert to some previous release : same problem with 3650, 3641.
If I replace replace the files with the github.com/textpattern/textpattern (mirror not up to date) : here, it’s ok !
I check the database and I delete the textpattern files before to upload the new files to avoid any problem …

Last edited by jpdupont (2012-02-24 17:40:06)

philwareham · 2012-02-24 17:51:18

There are some fundamental (and unfinished) changes to how articles are saved in the latest few SVN builds (using AJAX instead of reloading the page entirely). It’s probably an issue between that and a plugin – try disabling all your plugins and see if that works? FWIW I’ve tried creating a new article using r3661 and it worked fine for me, but my test install has no plugins added.

I really wouldn’t recommend installing SVN builds on any production site or development projects – stay with stable builds for that.

Last edited by philwareham (2012-02-24 17:52:02)

jpdupont · 2012-02-24 18:29:34

Thanks, Phil.

I try on a site without any plugin activated, but a site where I have cleaned all the demo stuff. And here I have the bug.

Dragondz · 2012-02-24 19:59:49

Hi

havent tested the release, but if it s a javascript issue maybe it s a cache problem!

jpdupont · 2012-02-24 20:34:21

No problem on a new install, without cleaning anything.

Other problem :

Warning: Invalid argument supplied for foreach() in /home/dorg/public_html/txpdemo/textpattern/include/txp_category.php on line 257

on category tab if no article has category selected.

jpdupont · 2012-02-24 20:43:06

I have found the bug.

It occurs when comments are closed in advanced settings.

Nothing to do with plugings or other stuffs, on my fresh new install.

Gocom · 2012-02-24 22:03:58

So… how are we supposed to updated the fields (on the fly) on save now then? With fairy-dust and unicorn rainbows?

wet · 2012-02-25 05:36:24

jpdupont wrote:

It occurs when comments are closed in advanced settings.

Thanks for the report. This issues has been fixed with r3662.

Gocom wrote:

With fairy-dust and unicorn rainbows?

Basically, yes. Some code may help, too. Here’s a few pointers for recommended reading:

For fairy-dust, use the new plugin types 4¹ or 5² (This is a tentative change I’d love to gather your input upon).

Plugin type 4 runs on the admin side for both synchronous HTML and asynchronous AJAX/Javascript responses (i.e. $app_mode is not considered by the plugin loader)
Plugin type 5 runs everywhere: Public, sync, async. Neither $app_mode nor txpinterface are considerd by the plugin loader.
Plugin type 3 from TXP 4.4 and previous is restricted from loading when $app mode == 'async'. This helps to avoid problems with plugins which emit HTML while the core waits for a JavaScript response in async app mode.

Unicorn rainbows are found under the label “pluggable ui” and “partials”³.

The article write screen is divided in to a set of partials.
Partials come in two flavours: PARTIAL_STATIC and PARTIAL_VOLATILE .
Static partials are expected to render their content once with the inital response for the page.
Volatile partials are expected to render their content for every subsequent async update.
Both types of partials can make use of pluggable_ui callbacks. They must react on the current $app_mode, and must not send HTML when the core expects JS.
I am still looking for a method which allows plugins to modify the currently hard-coded partial definitions⁴

You can look at my fork of zem_article_info to see a sample of this concepts in real code.

The usual callback for article.save is still here, of course. You’ve just got to make sure that your plugin is loaded when it occurs and that your plugin sends a response with a proper mime-type .

¹ r3651

² r3653

³ $partials

⁴ TODO

jpdupont · 2012-02-25 06:44:47

Thanks Robert,

Have you see this warning in the category tab, when

Articles categories exists
Articles exists but without categories assigned.

—> In a fresh new install, remove the 2 categories from the demo article.

Gocom · 2012-02-25 08:27:46

Robert, thank you for the reply.

wet wrote:

For fairy-dust, use the new plugin types 4 or 5 (This is a tentative change I’d love to gather your input upon).

Any idea how plugin cache plays with all that? I know there are a lot of guys that use it or similar solutions. For example I load all my plugins from static PHP files via loader plugins (one for each type which makes the plugin to respect the types etc).

I am still looking for a method which allows plugins to modify the currently hard-coded partial definitions

One plugin rule them all, as with pluggable_ui? Are that and pluggable_ui going to get referencing support or similar? Just so that it’s not either one of bot_wtc, glz_cf or rah_bitly.

Volatile partials are expected to render their content for every subsequent async update.

Any example of how one would feed data for async update fetch. Let’s say that custom field’s data changes after every save (post-processing), and that new data should be fed to the form. In 4.4.1 one can do that on save step by modifying POST data (or some JS). How will we do it in 4.5.0, for example in case of rah_bitly?

Rah_bitly will fetch a URL from Bitly and add it to custom field. How can I use partials to do the updating, while keeping resource usage the same (or better). To avoid making simultaneous connections to Bitly server, the custom field needs to be updated before next sync.

wet · 2012-02-25 10:12:45

Gocom wrote:

Any idea how plugin cache plays with all that?

None. The plugin cache at its current implementation is only a half-hearted attempt.

We have no built-in support for types, priorities and life cycles (we never had them), so basically it’s up to the plugin author to manage her plugin’s states. One could think about a more sophisticated implementation, e.g. by having distinct directories for the various plugin types, or keeping plugin all metadata in the database and just cache the code in the file system. Suggestions (or even patches, gasp!) are welcome.

One plugin rule them all, as with pluggable_ui?

Not necessarly. But I’m not quite sure how to handle the conflicts which will inevitably occur when more than one plugin has its vote about a partial.

Are that and pluggable_ui going to get referencing support or similar?

pluggable_ui should have been built with references. It was an oversight when it was introduced, but I think we should work towards this target. I’d need more thoughts about back compatibility, possible conflicts and how to resolve them. Speak your mind!

pluggable_ui and $partial definitions differ in a very important aspect:

The user interface is a cumulative resource: With a bit of courtesy from each plugin author, each plugin may add or subtract its parts without affecting the others.
partial definitions are an exclusive resource: You cannot have two conflicting settings at the same time, but need to resolve and elect one winning setting .

How will we do it in 4.5.0, for example in case of rah_bitly?

I will try to cast your plugin into a 4.5-compatible shape – or cast TXP 4.5 in a rah-compatible shape ;) Watch this.

Gocom · 2012-02-25 18:40:47

wet wrote:

keeping plugin all metadata in the database and just cache the code in the file system. Suggestions (or even patches, gasp!) are welcome.

That might be the best option; gets rid of the forever running glob too. But it doesn’t necessarily make plugin management any easier. Which is why guys use it; to be able to install plugins via a single commit.

I will try to cast your plugin into a 4.5-compatible shape – or cast TXP 4.5 in a rah-compatible shape ;) Watch this.

Nice. If you do a pull request, I will do a merge :-)

Last edited by Gocom (2012-02-25 18:44:23)

Textpattern CMS

Textpattern CMS support forum

#1 2012-02-24 16:42:11

r3661 error when saving an new article

#2 2012-02-24 17:51:18

Re: r3661 error when saving an new article

#3 2012-02-24 18:29:34

Re: r3661 error when saving an new article

#4 2012-02-24 19:59:49

Re: r3661 error when saving an new article

#5 2012-02-24 20:34:21

Re: r3661 error when saving an new article

#6 2012-02-24 20:43:06

Re: r3661 error when saving an new article

#7 2012-02-24 22:03:58

Re: r3661 error when saving an new article

#8 2012-02-25 05:36:24

Re: r3661 error when saving an new article

#9 2012-02-25 06:44:47

Re: r3661 error when saving an new article

#10 2012-02-25 08:27:46

Re: r3661 error when saving an new article

#11 2012-02-25 10:12:45

Re: r3661 error when saving an new article

#12 2012-02-25 18:40:47

Re: r3661 error when saving an new article

Board footer