It's me again! I know I'm annoying ;D
Found a bug while randomly testing stuff on BurkeKnight's forum. Do note the forum has been converted from SMF to Elkarte.
Installed addons:
1 reCaptcha 1.0.0 [ Uninstall ] [ List Files ] [ Delete ]
2 Spoiler Modern 0.0.1 [ Uninstall ] [ List Files ] [ Delete ]
3 Ultimate Menu 1.0 Beta [ Uninstall ] [ List Files ] [ Delete ]
4 Censored Words 1.0 [ Install Add-on ] [ List Files ] [ Delete ]
5 SimplePortal 1.0.0 Beta 1 [ Uninstall ] [ List Files ] [ Delete ]
6 Topic Solved 1.0 [ Uninstall ] [ List Files ] [ Delete ]
7 Users online today 0.2.1 [ Uninstall ] [ List Files ] [ Delete ]
8 Multi Badges 0.1.0 [ Uninstall ] [ List Files ] [ Delete ]
9 Hide User Names 1.0 [ Install Add-on ] [ List Files ] [ Delete ]
10 Inline Attachments 1.0 [ Uninstall ] [ List Files ] [ Delete ]
11 Remove Last Edit By 1.0.0 [ Uninstall ] [ List Files ] [ Delete ]
12 ElkArte 1.0.4 patch 1.0 [ Uninstall ] [ List Files ] [ Delete ]
So basically what goes wrong is that this link (http://www.webmastershaven.net/%7Bunread_all_url%7D) redirects to a 404 white page, saying "The requested URL /{unread_all_url} was not found on this server." (in case it wasn't clear it's the action=unread;all)
Apart from the fact that the link is broken for reasons that we still have to clarify... The issue is that the forum doesn't redirect to the board index as it should with non-available links, broken ones etc instead of a 404 page.
This happens to 3 sites, all converted from SMF to ElkArte.
However, a 4th site, also converted, does not have this issue.
But, the 4th site, used install of Elk 1.0.4 where the other 3 were done with 1.0.3 then used the update patch to 1.0.4.
EDIT:
We had another 1.0.4 install that was a conversion of yet another SMF site. That also has no issue.
This should confirm that it is something missing in the 1.0.4 update package.
Sorry, but it's still slightly unclear to me...
Are you talking about:
http://www.webmastershaven.net/index.php?action=unread;all ?
If so, it works just fine as a guest showing the login page.
And works fine here (do note it's the ".it" website):
http://www.elkarte.it/community/index.php?action=unread;all
that was updated to 1.0.4 via package manager.
Then, another little thing I'm not sure about: you are talking about 404, but action=unread doesn't need a 404 at all since it's a perfectly valid action, so it should just show the page it is supposed to serve and not a 404.
That said,
@Burke Knight could you check the server error logs to be sure what the actual error is?
If you go to either unread posts or replies, and it says there are none and has the button to look for all unread, the button is the issue. The link's variable is messed up. Need to be logged in to see it.
EDIT:
Attached screenshot of what URL says, when hover over the button.
Okay, that's almost completely different from the OP, but now I have another point to look at. :P
On the same forum as above the situation is still correct: the url is right and doesn't contain the {unread_all_url} bit.
I upgraded also:
http://testing.elkarte.it/elk/index.php
straight from 1.0.1 up to 1.0.4 and as you can see from the attachments the url looks good.
Based on the elements I have at the moment, I'd say the problem is due to an addon that reloads the index language file after the string has been replaced... no idea which one.
I'd keep this here just because I'm quite sure replace strings like that is at least bad practice (and I'm guilty, because I used that trick in some places), so they should be phased out "at some point", probably in 1.1 we should start using $context and maybe keep the string replacement just to reduce impact on backward compatibility, but that is debatable at least.
Yet, all the forums have the same addons. LOL
I'll look when can, to see what may have done differently.
The latest version of the SimplePortal mod.
When set it to disabled, the link goes normal.
Also, if set to front page, get this:
An Error Has Occurred
Unable to load the 'main' template.
Always in the "unread" pages?
Yes, that's the only place that button is shown, that I'm aware of.
And this seems to only affect that.
Sorry, bad wording, I was thinking at the unable to load the main template. :)
The unable to load the main template is main page if set portal to front page mode.
Oh, okay!
Anyway...
@Spuds that's your doing! :P
Still... It's a triple bug to me.
1) SP messing up the unread;all URL.
2) Front page unable to load main template.
3) Elkarte itself not redirecting to board index with that unread broken link.
I'll try to look into this over the next couple of days, I'm a bit over extended in what I have to get done over the next couple of weeks so it may take me a bit to get to this one, sorry !
@Spuds Okay, the main template error, is visible on fresh install of 1.0.4 and sites updated to 10.04 from 1.0.3.
The button to "Click here to try all unread topics" issue, however, is only present on sites updated to 1.0.4 from 1.0.3. Sites that had been fresh install using 1.0.4 are not affected by this odd bug. Does this mean that something in the full install of 1.0.4 maybe inadvertently fixed whatever it is?
That one absolutely not.
Elk doesn't use pretty/friendly/etc. urls. The gateway is index.php, anything that doesn't point to index.php is just ignored (apart few exceptions), so the response to random urls is not within the scope of elk at this moment. It would be the day Elk starts using friendly urls by default, but not at all now (and even later on, it should not show the board index, but a 404 page).
@emanuele What I think he means, is since the URL is not working right, it's getting the 404 error, instead of redirecting to the main page.
However, I think that's going to be normal, since the error due to the SP mod, is stripping the scripturl from it, so it wont redirect. It will get the 404, since it's treating the link as a complete page, and not part of the forum.
I didn't think about it emanuele, true :) It's because it doesn't have the index.php part. Scratch that then.
/me slaps
@Flavio93Zena around a bit with a large trout.
Where's that dislike button when I need it? ???
/me thinks a slap button would be more effective. :P
Ehy you two stop making fun of me D: offended
xD
That is very strange that it only occurs on sites updated to 1.0.4 from a previous version, not sure what to make of that. Maybe uninstall and reinstall SP to "reset" the hooks. Really that should not matter, but until I get a change to dig in to this I'm ???
@Spuds Tried it, and no-go...
Which is strange to me, because really, the idea sounded pretty sound.
Seemed like it was a hook issue, but now, not too sure....
Thank you for giving that a try, looks like I'm going to actually have to do some work :D
While I ponder what is going on ... for the can't load the main template error, for now I'd say just add
function template_main(){}
to the Portal.template..php file obexit() is calling that template, just not sure from where or why.
On the recent posts link error, how do you have the blocks defined? Are those blocks there for all actions, and which blocks specifically are on that page. Trying to reproduce that error.
Where add that line in the file? Anywhere?
All side blocks are set to everywhere, as is the news and shoutbox, and the footer affiliates block.
I had tried before, to disable the blocks, but it made no difference.
The /%7Bunread_all_url%7D error seems to be caused by the who's online block, at least when I disable that block the link goes back to normal. So right now I've at least duplicated the issue :D
Just anywhere will do, put it at the end, it really does not matter. Just don't add it inside one of the functions of course.
File edit worked.
As for it being Who's Online block, that seems to be it.
But, why is it not affecting forums that were 1.0.4 installs, and just those updated to 1.0.4?
The 2 sites that are 1.0.4 installs, still do not have this issue, but they do have the Who's Online Block. Strange... LOL
EDIT: Test site now has the issue, yet the other one does not.
Looking at the who's online block, it has
loadLanguage('index', '', false, true); its that last true that forces the reload of the index language and I'd suspect that is what is stomping on the substitution. TBH I'm not sure why that is there, its how it was/is in SP 2.3, not sure if it was just and sm thing and if its still needed :scratch head:
So, the quick fix should be to add after the above line:
$txt['unread_topics_visit_none'] = str_replace('{unread_all_url}', $scripturl . '?action=unread;all', $txt['unread_topics_visit_none']);
That did the trick. :)
This now inadvertently causes WSOD for the Ultimate Menu addon. :P
/me wonders why him and Ninja end up finding these strange oddities....
Probably because we are both professional bug spotters :P
More like, the bugs are professional us spotters. :P
;D
Lol...
Guessing it's because of a a template_main function in the mod as well.
That's tricky, template_main should
really not be used, because of this very reason.
Best guess:
if (!function_exists('template_main')) {
function template_main(){}
}
Not bullet proof, on the contrary it may very well fail the same way, but probably worth a try.
No, still can't access settings page for Ultimate Menu.
I was wondering if a particular block was causing it, but seems not to be.
I've disabled all blocks, and still have the error.
EDIT:
I wonder, how would I add that bit to an if statement, to work, only on the main portal page, and no other page or action?
Well for the experiment lets try this for the time being ...
rename the
function template_main(){} that you added to the Portal.template..php to
function template_portal_main(){}Then in your sources directory find the file PortalIntegration.subs.php then find the following section
// Something portal-ish, then set the new action
if (isset($file, $function))
{
add after that
$context['sub_template'] = 'portal_main';
That should fix the main template conflict and should fix the problem, but I'm entering this on the fly and have not had time to do much testing O:-)
Well.... Finally can do this new site, without wondering if needed to make a toggle in Admin, to add/subtract the line from Portal.template.php! LOL :)
Works like a charm, from what I can see.
@Spuds my friend, you are going to think this is as odd as we think...
I did the changes to all affected sites.
Now, the new one working on, seems to be the only one, with new issue, that goes away, if disable the portal.
Member Groups Page: missing all under the menu, as screen shot shows.
The Add Membergroup and Settings tabs work fine... it's just the Membergroup list tab....
EDIT: Can add 2 more pages: "Browse Files" & "Attachment Directories" both, in Attachments and Avatars section.
Looks like buildList() rears its ugly head ... not sure what to do ATM, will give this a look this weekend
Strange thing is, it's only the one site.
The portal files are all clones of the ones in WebMasters Haven site. Same with theme, except a couple minor changes.
Thats strange, but the issue was the drity work around I was trying to do ... anyway I had a thought, so let me try one thing on a test site and if it works I'll post it here in a few mins
OK .. once again on the run (sorry about this), but try the following:
First remove the the edits done to date, meaning remove the empty function we added to Portal.template.php and remove the line that was added to PortalIntegration.subs.php
Now find in PortalMain.controller.php
public function action_sportal_index()
{
global $context, $modSettings;
// Showing articles on the index page?
if (!empty($modSettings['sp_articles_index']))
{
require_once(SUBSDIR . '/PortalArticle.subs.php');
$context['sub_template'] = 'portal_index';
and replace it with
public function action_sportal_index()
{
global $context, $modSettings;
$context['sub_template'] = 'portal_index';
// Showing articles on the index page?
if (!empty($modSettings['sp_articles_index']))
{
require_once(SUBSDIR . '/PortalArticle.subs.php');
That should make the sub_template available to the front page (so we don't get the can't find the main template error) but sill allow the buildList function to add its sub_template ...
Looks like it's working. :)
Now, even though the issue did not do that oddity on the WH site, I'll also apply the changes there, as well.