Coranto 1.30.3 is out

[Groterra]

Cerberus,

I have tried profiles with coranto 123 also. They work fine.

from my understanding, he has a profile with multiple news. And in the .txt file all the news gets the same subject, as if the field subject does not get refreshed at each build run. So if he has 10 news, they all end up with the same subject even if they have different bodies. But would be something really peculiar.

Profiles print the following way (with default sort order only):

Subject 3
Snip text 3
Subject 2
Snip text 2
Subject 1
Snip text 1

If I do a full rebuild:

Subject 3
Snip text 3
Subject 2
Snip text 2
Subject 1
Snip text 1
Subject 3
Snip text 3
Subject 2
Snip text 2
Subject 1
Snip text 1

If I publish a new message it seems like:

Subject 4
Snip text 4
Subject 3
Snip text 3
Subject 2
Snip text 2
Subject 1
Snip text 1
Subject 4
Snip text 4
Subject 3
Snip text 3
Subject 2
Snip text 2
Subject 1
Snip text 1
Subject 4
Snip text 4
Subject 3
Snip text 3
Subject 2
Snip text 2
Subject 1
Snip text 1

I have made these tests in a system with 11 different txt profiles without parahead mod. I have fixed the bug in eight profiles using Unsorted (Reverse Chronological) for interliking. But three profiles (equals to another) with default sort order have printed normally without the bug. When I saved something one of these three profiles disclosed the bug. Very weird.

Parahead, I'll send you modified crcore.pl asap

[Parahead]

Parahead, I'll send you modified crcore.pl asap

Thank you for your modifed version of crcore.pl, you have implemented the fixes correctly, so we can rule out that option... Sorry again for the "misstrust" in you not being able to implement the fixes correctly.

What I became a bit confused about is the scenario you have specifed above, particulary the last part when you add a fourth newsitem, are you sure about that one? Could you conduct a test; Start from scratch (=remove the generated txt-file for this profile) with a certain amount of newsitems (for example 3). [Do a full rebuild and make a note on how the newsitems are ordered.] If you then post another newsitem, how does the txt file looks like? Scenario two would be to *not* do the part between [ and ], does that change anything?

What I am a bit puzzled about is the fact that in your last scenario in you previous post you have specified the fourth newsitem 3 times, which would indicate that the *file* isn´t just appended but it is actually being rebuilt, but it would mean that the variable $newshtml is appended. But this is really strange...

Sorry if I have asked this before but which addons do you have (more than FbF 2.0) and versions of them?

[Groterra]

This is the result of tests I made with addons below. Profiles were filtered by time and number and 1 (one) filtering by Filter by field2, multiples categories, headlines disabled. Sort order = Default (Reverse Chronological).

1 a - With crcore.pl modified by parahead (without changdatenew and filterbyfield2) all .txt files were built correctly.
1 b - With original crcore.pl (without changdatenew and filterbyfield2) only one .txt profile which was set to skip the first 1 item disclosed the bug.

2 a - With crcore.pl modified by parahead (+ changdatenew + filterbyfield2) all .txt profiles disclosed the bug.
2 b - With original crcore.pl (+ changdatenew + filterbyfield2) all .txt profiles disclosed the bug.

3 a - With crcore.pl modified by parahead (- changdatenew + filterbyfield2) all .txt files were built correctly.
3 b - With original crcore.pl (- changdatenew + filterbyfield2) some .txt profiles disclosed the bug, including one which was set to skip the first 1 item

4 a - With crcore.pl modified by parahead (+ changdatenew - filterbyfield2) some .txt profiles disclosed the bug, including one which was set to skip the first 1 item
4 b - With original crcore.pl (+ changdatenew - filterbyfield2) only one .txt profile which was set to skip the first 1 item disclosed the bug

The addons active were:

cra_SpecialLinks.pl
cra_abacus.pl
cra_addonenabler.pl
cra_annoynot.pl
cra_guestpost.pl
cra_backup.pl
cra_countitems.pl
cra_cssedit.pl
cra_customfields.pl
cra_ezStats.pl
cra_fieldhelper.pl
cra_htmlbuild.pl
cra_liaison.pl
cra_loggedin.pl
cra_maginot.pl
cra_modifyNewsCatFilter.pl
cra_modifynewsincludefield.pl
cra_modifyusercol.pl
cra_moveit.pl
cra_multipage.pl
cra_multipart.pl
cra_ncategory.pl
cra_netlink.pl
cra_newfilesadv.pl
cra_newscolumns.pl
cra_npreview.pl
cra_pbuild.pl
cra_pm.pl
cra_prisoner.pl
cra_queryfetcher.pl
cra_relatednews.pl
cra_requiredfields.pl
cra_rssfileadv.pl
cra_selectimage.pl
cra_sortorders.pl
cra_tmpl.pl
cra_urlcolumn.pl
cra_user-profile-pages.pl
cra_xmultisubmit.pl

[Parahead]

groterra, thank you so much for this extensive testing, much appricated, really!

OK, by looking at you report it looks like it is something in conjuction with the ChangDateNew addon that is messing things up. Which version of that addon are you using?

[Groterra]

Parahead, I'm using version you have modified. I'll try to replicate test with old ChangDateNew addon.

[Parahead]

Parahead, I'm using version you have modified. I'll try to replicate test with old ChangDateNew addon.

Stupid, stupid me... I have had too much on my mind lately, I had totaly forgotten about me adding support for the countnews hasharray in ChangeDateNew 3.2 in order to comply with this new behaviour in the 1.30.x series. That was before we discovered the small bugs involved in the building and then started altering the location of the incrementation in 1.30.3, so all you have to do is remove one line of code. I havn´t tested this myself, but it *should* be the thing causing the problem.

Remove line 305 in cra_changedatenew.pl (version 3.2):

Code: Select all

$countnews{$i}--;


Please report back if this solves the problem...

[Groterra]

These are the results of tests I have made with original changedatenew and changedatenew mod by parahead ( without $countnews{$i}--; ). Profiles were filtered by time and number and 1 (one) filtering by Filter by field2, multiples categories, headlines disabled. Sort order = Default (Reverse Chronological).

1 a. With crcore.pl modified by parahead + changedatenew mod by parahead - filterbyfield2 = OK, .txt files have been built correctly
1 b. With original crcore.pl + changedatenew mod by parahead - filterbyfield2 = profiles have disclosed the bug, including one which was set to skip the first 1 item

2 a. With crcore.pl modified by parahead + original changedatenew - filterbyfield2 = OK, .txt files have been built correctly
2 b. With original crcore.pl + original changedatenew - filterbyfield2 = only one profile which was set to skip the first 1 item disclosed the bug

3 a. With crcore.pl modified by parahead + original changedatenew + filterbyfield2 = OK, .txt files have been built correctly
3 b. With original crcore.pl + original changedatenew + filterbyfield2 = profiles have disclosed the bug, including one which was set to skip the first 1 item

4 a. With crcore.pl modified by parahead + changedatenew mod by parahead + filterbyfield2 = OK, .txt files have been built correctly
4 b. With original crcore.pl + changedatenew mod by parahead + filterbyfield2 = profiles have disclosed the bug, including one which was set to skip the first 1 item.

5 a. With crcore.pl modified by parahead - changdatenew + filterbyfield2 = OK, built .txt files correctly
5 b. With original crcore.pl - changdatenew + filterbyfield2 = profiles have disclosed the bug, incluidng one which was set to skip the first 1 item

[cerberos76_]

Ok, thanks a lot both to groterra and Parahead.
The situation is very clear now.

Coranto 1.30.3 has a small bug in the building process and in particular in the index increasing. the bug can be easily fixed by moving the counter increase in a different position. Coranto 1.30.4 will include this fix.

ChangeDateNew latest version by parahead has a small bug (born out of an attempt to cure the main build bug...). This bug is remoed by simply removing hte countdown. I assume parahead will soon release a new version for ChangeDatenew and all will be sorted out!

Thanks again.

[Parahead]

ChangeDateNew latest version by parahead has a small bug (born out of an attempt to cure the main build bug...). This bug is remoed by simply removing hte countdown. I assume parahead will soon release a new version for ChangeDatenew and all will be sorted out!

Well, maybe I am nitpicking but it wasn´t in an attempt to cure the main build bug, it was in an effort to try and comply to the new counterarray (which exists in 1.23 as well!) and it only "became" a bug when 1.30.3 was fixed, but never the less, I will release a new version of ChangeDateNew with the countdown line removed, sorry for any inconvience...

[Parahead]

cerberos76, just wanted to point out this thread where we discussed to implement the two hooks DisplaySubForm_Fields_2 and ModifyNews_Edit_Fields_2 in the 1.30.x series. The updated version of 1.30.3 that I sent you before did not contain this modifications to the subs DisplaySubForm and ModifyNews_Edit mentioned in that thread... Would be nice to see those hooks in the 1.30.4, so let me know if I should give you a hande and send over those modified subs with the 1.30.3 as the source.

[shanemckiness]

...So is the 1.3 series out yet?

Shane

[Parahead]

...So is the 1.3 series out yet?

There is no thing as 1.3, but 1.30 and yes, it is "out" and has been so for quite some time, but it is still a beta if that is what you really asks? And I don´t *think* that it will be called 1.30 when it is officially released as stable but 1.31 instead.

[shanemckiness]

Ooo. Sorry.

[Parahead]

cerberos76, what are the plans for releasing a new version in the 1.30.x series? The patched version of 1.30.3 which I sent to you about two months ago should take care of the issues discussed in this thread, maybe that could be cleaned from comments and released? Feels like the 1.30.x series currently is on hold?

[cerberos76_]

1.30.5 will come very soon. check email...