Joomla! Discussion Forums

Many thanks for setting up the hack predator and ken.

This might be a moot point as you're that much closer to a 1.1 release, and moreover I'm not up to speed with all those string manipulation functions involved with the hack to call this a bug, but in the 1.0.3 revision 2, multiple wrapper URL menu items in a site to different URLs all resolve to http://mysite.com/wrapper/, and appear to default to the wrapped URL with the 'lowest' menu ItemID.

Line 1023-4 of sef.php currently looks like this:



Here's a potential fix for making the pretty URLs at least: replace the lines above with the following:

Code:

} else if (eregi("option=com_wrapper",$string)) {
                    $temp = split("&Itemid=", $string);
               $temp = split("&", $temp[1]);
               $database->setQuery("SELECT name FROM #__menu WHERE id=".$temp[0]);
               $sefstring .= sefencode($database->loadResult())."/";
               $string = $mosConfig_sef_components."/".$mosConfig_sef_wrapper."/".$sefstring;

Though I'm definitely missing something here: picking up the wrapper's ItemID...I look down a little bit and I see that long getID function.  Any thoughts?

Marko, Great job on CoreSEF.
Not sure if this is a known bug, but it appears that the "Remove Characters:" code is not currently working.
It appears that this may be due to sefencode and sefdecode. The issue first seems to pop up on

Where the array isn't built as intended.
I'm also not sure if is intentional, as this would replace $value with $value.

Let me know if I'm missing something here, or if this is a known problem.

I'm running into the same wrapper problem. I have three wrappers leading to different html forms. The wrapper menu buttons all resolve to the same form when the Advanced SEF urls are on.  Plus the remove characters and the short and long url option, don't seem to work correctly for me either, it alwasy uses the title and not the title alias.

Predator,

Will this still work with 1.0.4? And if so will it compromise security as I see there was a potential problem with the default sef?

Cheers 

Just upgraded to 1.0.4 on one of my low-risk, low-traffic sites.  Looks like it caused the hack not to pick up a couple of its parameters.

- SEF Mode
- Length of URLs
- Lower-Case All URLs
- Home menu URL

An updated Version is here:

http://developer.joomla.org/sf/frs/do/v ... a_1_0_4_r1

Thanks Predator! You da man!

Ah, another two-minute upgrade?  Just overwrote and it's working great now.  Thanks!

This potential problem is also fixed in the CoreSEF hack. The next 2 weeks i have a lot of time so will fix also the other issues.

Can you make Future Request tracker on Forge?

Feature Request Tracker is added

Hi.
Thank you for this work - i very like it, but there is one issue - i'm using as a frontpage Static Content - so i got a lot of troubles with Home-menu link - it takes me to the last of the added content items if i clik on Home-menulink - so i think it will be whery good if you add the option to use the Static content as a frontpage in your hack.
Thanks!

Have 2 questions:

1. Is the problem with joomlaboard solved? If so, please tell me how, as I`m still experiencing problems : when I want to open a new topic or post a reply I get an almost blank page - just site template and forum navigation. Plus, that problem with Invalid ID.

2. My site/language is using such characters as č, ć, š, and ž. And if I don`t exclude `em from URL I get URLs with "%e8" instead of "č" and similar. If I exclude`em my URLs are not so descriptive/correct (i.e. like if joomla would be jooma in URL). I hope you know what I mean.

My question: Is there a way I can replace "č" and "ć" with "c", "š" with "s" and "ž" with "z"?

Thanks,
Vukan

On the top of the sef.php you see:

// specify the special chars for replace but need a better place for this
$url_replace = array(
"�" => "ae",
"�" => "aa"
);

and replace it with:

// specify the special chars for replace but need a better place for this
$url_replace = array(
"č" => "c",
"ć" => "c",
"š" => "s",
"ž" => "z"
);

Strange ...
Some URLs work some don`t.
Check my site: http://www.zalogaj.com/

I.e.:
http://www.zalogaj.com/razno/razno/o-hrani-uopste.htm (works)
http://www.zalogaj.com/recepti/glavna-j ... jivama.htm (doesn`t work)
And both has the same character replaced - "š" => "s",


Note: Didn`t replaced all - I just replaced "š" => "s" and "ž" => "z"

Hmm strange will check this deeper

Hi,

i also had the effekt with the german special characters,
i replaced ß with ss  and i hat a URL where ss was in the normal Text
so the backreplace took place an kaboom the link won't work.

perhaps this helps a litte

greets

Roberto

Roberto,
Didn`t understand. Could you please clarify?

Some URLs without these characters at all - doesn`t work also(!) i.e. http://www.zalogaj.com/recepti/salate/s ... ompira.htm
Please help asap!

Thanks,
Vukan

Anybody?

Hello Vukan,
is was late yesterday and ist was a "go to bed post" :) 

my answer were ment as a hint to the developer for finding your issue.

Im sorry i havn't the solution persent, but i try to clarify my assumption:

The replace Funktion works in 2 Ways, first articlename -> Url and the second Url-> find Article.
The First makes every  "š" => "s" and the second  every!!!  "s" => "š"


1st foreach ($url_replace as $key => $value) {
$string = ereg_replace($key, $value, $string);
}
2nd foreach ($url_replace as $key => $value) {
$string = ereg_replace($value, $key, $string);
}
the only Problem is, when the name is "monster" the 1st doesn't anything bit the 2nd makes "monšter" of it,
this is not a valid articlename an then the corehack goes to the fedined error page (in your case the frontpage)

--> Try to replace with multiple characters i.e. "š" => "sz" or somthing like that (a kombination that isn't in normal words!)
then try again.
This would be easier to track if the system had a debug mode where it says  Blog "monšter" not found in Database or something like that.

puh i hope this makes things clearer

greetings Roberto

Hi Roberto,

Got it now  Thanks.
But if that`s how this script works, I guess it would be simpler just to exclude those characters in Global Config.

I`ll probably have to rewrite these coresef files, because my simpleboard doesn`t work + this stuff with characters

Helping fixing is everytime welcome

I think I may have fixed an error with the pagination.

At the moment there are problems with the pagination on all sets of pages, items, blogsection, blogcategory and frontpage.

This fixes the pagination for items only

On line 877 in sef.php of coresef hack

Change this line:

  $sefstring .= "/".$temp[0]."/";

to this line:

  $sefstring .= $temp[0]."/";


Seems to work well and no other conflicts.

I would really like to get blogsection and blogcategory fixed, these are only showing one number /9/ in the URL when i believe it should be two /1/9/

Would be grateful for some help in fixing these issues

Hi, i did a hack which could be the base for further discussion on how to solve the "Remove Characters" issue


In the Backend insert !|$|,    as Remove Characters

in 1154 $string = eregi_replace("\+", $mosConfig_sef_space, $string);
//ROBI Remove Characters HACK 1
foreach (explode("|",$mosConfig_sef_url_exception) as $value) {
$string = str_replace(urlencode($value), "", $string);
}
//ROBI Remove Characters HACK 1 END

in 613 $content_name = sefdecode($url_array[$pos+2]);

// ROBI Remove Characters HACK 2
if ($sef_longurl=="name") {
$database->setQuery("SELECT id "
."FROM #__content "
."WHERE REPLACE( REPLACE( REPLACE(title ,',', '') ,'$', '')  ,'!', '')='$content_name'");
//  Potential Characters  §|!|$|%|£|@|?|#|&|(|)|+|*|/|,
//ROBI Remove Characters HACK 2 END

HACK 1:
i replaced the separator by a "|" Symbol because i use the "," in my texts.
the old replace Function replaces not the defined characters on my system - heres a new one.

to get things work again we need HACK 2:
The search on the database needs to replace these characters too.
Here is a very dirty , limited sql modification.


___
Instead of putting the task of removing the characters in the hands of the database
all results could be first replaced an then compared, this would ease the implementation
but i think this isn't efficient. On the other hand the sef needs a cache to be efficient
an then some millis aren't the problem.

Let the Discussion begin

greetings Roberto

Hello again,

i worte these simple lines for easier debugging,
in the case the sef didn't find a url it doesn't redirect but puts some infos on the screen.
Especially when you play around with the replace or remove features i think this is useful. 

Greetings Roberto

in 710 mosRedirect($mosConfig_sef_404);
//mosRedirect($mosConfig_sef_404);
// ROBI HACK Debug
echo "NOT FOUND: ".$REQUEST_URI."
";print_r($uri);
//ROBI HACK Debug END

Hello,
here the third in line 
For Sites that use installations in subfolders use this hack

after 198 $url_array = explode("/", $_SERVER['REQUEST_URI']);

//ROBI HACK
$depth=substr_count(str_replace("http://", "",$mosConfig_live_site) , "/");
$url_array = array_slice ($url_array, $depth);
//ROBI HACK END

Greetings Roberto

Hi, I am having a problem with the coresef hack.

When I have un-published some old content on my joomla site, and someone clicks on a link to it from a search, on google for example, they are faced with a message that they are 'Not authorized to view this resource, blah blah'.

I would like them instead to be directed to the page I specified (my site's sitemap) for 404 errors in the sef configuration page in the admin panel.

Can anyone help with this please?

Any luck getting this to work with SMF yet?

Hi Marko

Please come back to this thread We need U

I am happy to help out if you can show me which bits of code are in the problematic areas we talk about

Are you going to continue this hack seeing as you released sefbot as well and its installable?

Any help is much appreciated 

Hi,

i think this isn't really a coresef problem because you have the same effekt without sef.
In my opinion it's easier to patch yoomla at the code where it writes the "not authorized" message.

Go to procomPortal/components/com_content/content.php line 1109  add   echo "Redirect!";
so you can test if there are no Sideeffekts (This ist the Else block wenn the Article istn't published or the publish Date is over.
If there are no Sideeffekts you can Do your 404 Redirect there. (You could use the $mosConfig_sef_404 from CoreSEF hack, because its Parameters are in the normal configuration.php)

I hope i could help a litte

Roberto