Support Forum
Support Forum
Offline
well that would be interesting... not sure how you wouldnt have it - its clearly in the install... I assume you havent modified your db tables since the install?
are your tables innodb or myisam?
you can just try to add it with a query in phpmyadmin:
CREATE FULLTEXT INDEX 'post_content' ('post_content')
if that doesnt work, maybe Andy (our resident mysql expert) will have some more ideas...
Visit Cruise Talk Central and Mr Papa's World
Offline
Sadly - following your comments on another thread - we can not do this without getting technical! But will do my best to explain.
MySQL - the database engine where all of your site data is stored - essentially has two different types of table type - storage format if you like. The most common - and the one that WP automatically will use - is called MyISAM. The other - better in many ways but more restrictive - is called innoDB.
As I say - by default most hosts set their mySQL up to create MyISAM tables as does the WordPress installer. The Simple:Press install script specifies myISAM in it's command code.
Simple:Press utilises an index type named FULLTEXT which is powerful and useful to implement search queries against. We create a FULLTEXT index on both the Simple:Press sfposts and sftopics tables. However, FULLTEXT indexing requires the table to be MyISAM. It will not work with innoDB. (OK - actually this is not quite true as I understand it. The most recent versions of MySQL do, I believe, now offer FULLTEXT support on innoDB tables. But - most, if not virtually all - hosting companies are always several versions of mySQL behind as they prefer to play it safe. I understand this bit it is a nuisance). It is one of the main reasons why Simple:Press specifically commands tables to be MyISAM - to get the FULLTEXT support needed for better searching.
Now- the only way I can think of that you are not seeing the FULLTEXT index is if your tables have been created as type innoDB against the commands of out install script. I have to say that I have not encountered such a thing happening before but it may be possible that your host company has set things up this way.
So the first thign to check - now we know the index is missing - is to find out the table type and you can do this using phpMyAdmin with the following steps:
- Launch phpMyAdmin and display the list of tables that make up your site database
- Locate the '...sfposts' table and click on the 'structure' link to the right of it.
- When loaded click on the 'Operations' menu item along the top of the display.
- Simply look at the third column - Table Options and see what it says the 'Storage Engine' is for that table.
- Close it down without doing anything else - it's a scary place to be if you clicked an option by mistake!
IF the engine is 'MyISAM' then we scratch our heads, wonder why the index was not created and walk you through creating it which is easy enough.
IF the engine is 'innoDB' then I would firstly ask your host why innoDB has been imposed against the table creation script and if those two tables (sfposts and sftopics) can be changed to MyISAM tables.
And then let's take stock.
 |
YELLOW
SWORDFISH
|
Offline
it is innoDB, I see a drop down menu that gives a option to change, will that mess up the install if I do? We host on wp-engine, I'm contacting the help desk now about it
Offline
contacted the help desk, they created a support ticket and are working on it, since we host on wp-engine I have a separate staging site with it's own database, would it be a bad thing if I just changed those two tables on the testing server database and see what happens?
Offline
I am, you will understand, hesitant to just say go ahead and do it. I think actually it will do just fine but I really would rather not be responsible for the decision!
You will need to create the FULLTEXT index after the table is changed as well of course. We can give you the details for those.
I am concerned that innoDB tables were created when the SQL script explicitly demands MyISAM. That just shoup=ld not happen and hopefully that is the reason for the bug ticket at the host.
|
YELLOW
SWORDFISH
|
Offline
totally understand on the first post
so say if I was going to attempt this, theoretically of course, I should change those two tables to MyISAM first and then try to create the index I am missing?
Theoretically of course.
Offline
That would be theoretically correct.
And the theoretical FULLTEXT index on sfposts would need to be on the post-context column and the theoretical FULLTEXT index on the sftopics table would need to be on the topic_name column and they can be named anything at all as long as it is unique...
|
YELLOW
SWORDFISH
|
Offline
Yellow Swordfish said
That would be theoretically correct.And the theoretical FULLTEXT index on sfposts would need to be on the post-context column and the theoretical FULLTEXT index on the sftopics table would need to be on the topic_name column and they can be named anything at all as long as it is unique...
theoretically I will report back
All RSS1 Guest(s)