Suggestion to fix OBEX
pedward
Posts: 1,642
The new OBEX breaks compatibility with all of the existing links in the forum and elsewhere, leading to the dreaded 404 error.
I would suggest that a simple, static, conversion script be put in place to fix these broken references.
The 3 axis CNC project is at /objects/901 in the old OBEX and /object/85 in the new OBEX, this seems very straightforward to fix with a table that has old/new entries. For objects that didn't make the cut, just don't populate them and redirect to a special page or to the OBEX homepage.
This script needs only to be static, since the migration has happened, so massaging a CSV file into a PHP array would be trivial:
Put that script anywhere on the OBEX server, then modify the Apache configuration to allow FileInfo override for that directory:
Then create a directory for /objects on OBEX and put this .htaccess file in that directory:
The path to the PHP script could be to the 404.php in that directory, or any other place, but where ever you put that script.
What this does is create a hook only for the /objects directory to launch a custom error handler that looks up the old OBEX object id and redirects to the new object id, all transparently.
This will fix the broken links that currently point to old object ids.
I would suggest that a simple, static, conversion script be put in place to fix these broken references.
The 3 axis CNC project is at /objects/901 in the old OBEX and /object/85 in the new OBEX, this seems very straightforward to fix with a table that has old/new entries. For objects that didn't make the cut, just don't populate them and redirect to a special page or to the OBEX homepage.
This script needs only to be static, since the migration has happened, so massaging a CSV file into a PHP array would be trivial:
<?PHP
$conversion = array(
'901' => '85'
);
$in = substr(strrchr($_SERVER['REDIRECT_URL'],'/'),1);
$out = $conversion[$in];
if ($out) {
header("Location: http://obex.parallax.com/object/{$out}");
} else {
header("Location: http://obex.parallax.com/");
}
exit;
?>
Put that script anywhere on the OBEX server, then modify the Apache configuration to allow FileInfo override for that directory:
<Directory /var/www/obex/htdocs/objects>
AllowOverride FileInfo
</Directory>
Then create a directory for /objects on OBEX and put this .htaccess file in that directory:
ErrorDocument 404 /objects/404.php
The path to the PHP script could be to the 404.php in that directory, or any other place, but where ever you put that script.
What this does is create a hook only for the /objects directory to launch a custom error handler that looks up the old OBEX object id and redirects to the new object id, all transparently.
This will fix the broken links that currently point to old object ids.
Comments
How does this work? I see that the new obex call is to
obex.parallax.com/object/nnn
whereas previously it was objects, plural...
obex.parallax.com/objects/nnn
Is objects, plural sufficient to distinguish the intent?
We are monitoring traffic on the OBEX and the frequency of 404 pages (which remains low), we are happy to see an increase of metrics flowing to the site again, and we have plans to help people find their older links connecting to the new system.
Please see my reply:
http://forums.parallax.com/showthread.php/147593-New-Propeller-Object-Exchange/page4?highlight=OBEX
Makes sense to keep the old OBEX so MANY old links will be intact until you figure out how to move them over. I have to send many people to the www.obexclassic.parallax.com when they can't find and object. Or should that information be a big sticky somewhere.?
Other people feel the same way.
Thanks for all the hard work you do behind the scenes!
I can't go into specifics, but there were factors at play which required immediate and drastic action to occur before getting even further out of control. We gathered some good stakeholders, knowledgeable people, and tossed up a solution as triage. We apologize for the inconveniences, and we promise when time allows we will spend resources to fix the issues.
I never said I was against anything. I acknowledged that your solution would work, but no table such as the one you referenced exists at this time; therefore it is not viable, until that table exists.
If you give me access to the data I can have a mostly complete table in a couple of hours most likely.
I need access to whatever databases were used for the old and new, then I can write some queries/scripts to extract the relevant information and make a best effort conversion table.
I like to use my tablet to view code thus I have to convert the spin files to PDF's (I use Google docs). It's a easy process to convert them and I do it for all of the Propeller code I'm working on however, I can't be alone and others must do it as well. Therefore, I would like to see a column in the object exchange with the converted PDF files for all the objects. Just think about how many trees and how many people hours we will safe .