Este sitio hace uso intenso de JavaScript.
Por favor habilita JavaScript en tu navegador.
Moderna
RPP
10.2.7
RPP
10.2.6
Beta
Add Wowhead tooltips to your forums or CMS.
Regresar al índice de los foros
Publicado por
22027
This post was from a user who has deleted their account.
Publicado por
Lockslap
That would be ideal, yes, but the only problem is that unless they supply an ID for the tag rather than the name, the script doesn't know the ID. The main problem is that the script doesn't currently support IDs for craftables and itemsets. Haven't gotten around to it yet. I script only knows the ID when it: A) gets it from Wowhead B) gets it from MySQL.
In my testing when using Scourgeborne Battlegear it displays the Heroes' set, which makes sense due to it being the first set listed on the search page when going
here
. However, when you do provide the Heroes' or Valorous prefixes it correctly gets and displays them, as well as saving them to the cache for later use.
Perhaps you could clarify what is going on, or even better show an example. That way I can better understand and fix it. Also changing define('WOWHEAD_DEBUG', false); to define('WOWHEAD_DEBUG', true); in config.php could point to the problem. This will turn on debugging mode which will messily display what it finds as it works it way through the code.
By the way, in a few minutes a pretty big update is coming (for the SMF users anyways =D).
What happens is if someone enters Scourgeborne Battleplate it displays the Hero set in the post and in your wowhead_itemset database table is placed the entry:
792 Scourgeborne Battleplate Scourgeborne Battleplate en
So far so good. It also makes several entries into the wowhead_itemset_reagent for each item in the set. Again, this is fine.
Now, if someone happens to make a post that has Heroes' Scourgeborne Battleplate it makes a new entry in wowhead_itemset:
792 Heroes' Scourgeborne Battleplate Heroes' Scourgeborne Battleplate en
This is fine, but now the problem occurs.The script makes new entries in wowhead_itemset_reagent for this "new" set but since it really is not "new" it has the same itemset number of 792 thereby duplicating what was already in that table and in effect creating two entries for every set item. If you now refresh the page both itemset links will have 2 listings for every item in the set because the wowhead_itemset_reagent table has two entries for each item.
In short, because the script sees Scourgeborne Battleplate and Heroes' Scourgeborne Battleplate as two different items it saves them both to the database as seperate items. But because they are the same sets with the same set ID you end up getting duplicate entries in wowhead_itemset_reagent which makes the forum post display all the matching items in that table, of which there are now two per item.
That's what I was thought you were talking about. The only problem is that I don't really have a way to prevent that from happening. The only way to get itemsets (right now) is by their name, so I have no way to check if the set id already exists in the database. When looking for something in MySQL the script will match what was originally searched for (aka search_name) first, then move on when it returns a row. It seems it may just have to be something you have to live with.
Publicado por
293107
This post was from a user who has deleted their account.
Publicado por
94191
This post was from a user who has deleted their account.
Publicado por
Lockslap
Sorry, my bad, uploaded my tweaked one instead of the default install.
Redid it with default and looks like its working perfect. Need to mess with it some more.
I notice the instructions are gone from your site.....
Edit:
Ok, played with it some more. This is on a default install of smf 1.1.7 and 3.02 of your tooltip script. Two things.
I can't get the tags to work, all the other tags are working fine, just need to play with the display a bit (what the links look like). Not sure why the icon tags aren't working. Seems like they don't get parsed at first, then they do and you see nothing in the post.
I also notice this error in the forum log:
2: in_array() : Wrong datatype for second argument
File: /xxx/xxx/xxx//wowhead/includes/wowhead.php
Line: 428
Yeah the error is nothing to worry about, just a way that I'm handling the patterns at the moment, I am working out a new way to do it. As far as the itemico go, looking in the source of your site (linked in your signature) I do not see a reference to the script's CSS file (wowhead). This is most likely why the icon tags aren't working.
As far as the installation instructions go the site seemed to have too much going on in the install section. So to clean it up I've started using
AJAX
to display the instructions based on what link they click in header of the install section. Just click SMF and it will magically appear.
Publicado por
Lockslap
I have a problem with that.
I uploaded folder to site, edited files, set up config, executed file to mysql, done all things.
When I try to put anything in tags, like:
Breastplate of fury
It writes error, that item x was not found. I checked language.
Log: (enabled debugging of wowhead and forum)
21407
Scourgeborne Battleplate
Heroes' Scourgeborne Battleplate
http://www.wowhead.com/?item=21407&xml
PHP Notice: in file /wowhead/includes/wowhead.php on line 90: Use of undefined constant fp - assumed 'fp'
http://www.wowhead.com/?search=Scourgeborne+Battleplate
PHP Notice: in file /wowhead/includes/wowhead.php on line 90: Use of undefined constant fp - assumed 'fp'
http://www.wowhead.com/?search=Heroes%27+Scourgeborne+Battleplate
PHP Notice: in file /wowhead/includes/wowhead.php on line 90: Use of undefined constant fp - assumed 'fp'
Open wowhead.php and goto line # 90.
On that line you will see
if (!fp)
change it to
if (!$fp)
then save it and reupload it to your site. I will release the fix in the next version.
Publicado por
293107
This post was from a user who has deleted their account.
Publicado por
94191
This post was from a user who has deleted their account.
Publicado por
Caldar
That's what I was thought you were talking about. The only problem is that I don't really have a way to prevent that from happening. The only way to get itemsets (right now) is by their name, so I have no way to check if the set id already exists in the database. When looking for something in MySQL the script will match what was originally searched for (aka search_name) first, then move on when it returns a row. It seems it may just have to be something you have to live with.
How about changing the caching query for the itemset items to check the itemset_reagent table first to see if $setid already exists and if it does then not save the items to the table once again?
Publicado por
308223
This post was from a user who has deleted their account.
Publicado por
Lockslap
That's what I was thought you were talking about. The only problem is that I don't really have a way to prevent that from happening. The only way to get itemsets (right now) is by their name, so I have no way to check if the set id already exists in the database. When looking for something in MySQL the script will match what was originally searched for (aka search_name) first, then move on when it returns a row. It seems it may just have to be something you have to live with.
How about changing the caching query for the itemset items to check the itemset_reagent table first to see if $setid already exists and if it does then not save the items to the table once again?
To be perfectly honest, I don't really see what the big deal is. Its a few extra bytes of DB storage, and does not interfere with the execution of the script. The only way I would be able to make it work properly would be to completely redo the reagents table and I have other things to fix/improve/write at the moment.
On a side note, I am going to be writing an armory tooltip script similar to this one, except that it would use Wow's armory to get the information. It will also use an AJAX Javascript file to parse links as you mouseover them, similar to how Wowhead's power.js file works. Obviously, I won't be talking about it as much on this site, given that it doesn't use Wowhead. I'm thinking I may release them as a Wow package, should be pretty damn cool.
Publicado por
Lockslap
Open wowhead.php and goto line # 90.
On that line you will see
then save it and reupload it to your site. I will release the fix in the next version.I edited that, but now:
Failed to add to the cache. You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' '', '40271', NULL, NULL, 'itemico', ' at line 15
INSERT into `wowhead_cache` ( `id`, `itemid`, `name`, `search_name`, `quality`, `rank`, `type`, `lang`, `icon`, `icon_size` ) VALUES ( NULL, , '', '40271', NULL, NULL, 'itemico', 'ru', '
http://static.wowhead.com/images/icons/medium/.jpg'
, 'medium' )
You're getting tha response because the script wasn't able to properly get the information it needed, and somehow it didn't report a failure (not found error). Most likely, given what you posted earlier your PHP installation isn't properly able to query Wowhead using the 3 methods that my script has available to it. The script is most likely not getting the proper XML info it needs to get the rest of the stuff it needs to display everything correctly. As you can see from
this page
that same itemico works properly using the Russian language.
Publicado por
94191
This post was from a user who has deleted their account.
Publicado por
Caldar
That's what I was thought you were talking about. The only problem is that I don't really have a way to prevent that from happening. The only way to get itemsets (right now) is by their name, so I have no way to check if the set id already exists in the database. When looking for something in MySQL the script will match what was originally searched for (aka search_name) first, then move on when it returns a row. It seems it may just have to be something you have to live with.
How about changing the caching query for the itemset items to check the itemset_reagent table first to see if $setid already exists and if it does then not save the items to the table once again?
To be perfectly honest, I don't really see what the big deal is. Its a few extra bytes of DB storage, and does not interfere with the execution of the script. The only way I would be able to make it work properly would be to completely redo the reagents table and I have other things to fix/improve/write at the moment.
On a side note, I am going to be writing an armory tooltip script similar to this one, except that it would use Wow's armory to get the information. It will also use an AJAX Javascript file to parse links as you mouseover them, similar to how Wowhead's power.js file works. Obviously, I won't be talking about it as much on this site, given that it doesn't use Wowhead. I'm thinking I may release them as a Wow package, should be pretty damn cool.
Its not a big deal, beyond looking stupid and incorrect. And while the script continues to run, it displays the information incorrectly.
Once this has occured, ever single time you link a set with or without the hero prefix you get double entries for ever single item in the set.
I use the exisiting wowarmory mod to provide armory data via links but I would appreciate an all in one package and look forward to that.
Publicado por
293107
This post was from a user who has deleted their account.
Publicado por
Lockslap
@b0n3Z, I don't know exactly what is going on with your installation, so I'm afraid I don't know if it will run properly. It just appears that for whatever reason your PHP installation doesn't allow the script to get properly get the information it needs from Wowhead. It could very well be a problem with the script's method of getting the data, but I have been unable to reproduce the problem on my webserver.
That's what I was thought you were talking about. The only problem is that I don't really have a way to prevent that from happening. The only way to get itemsets (right now) is by their name, so I have no way to check if the set id already exists in the database. When looking for something in MySQL the script will match what was originally searched for (aka search_name) first, then move on when it returns a row. It seems it may just have to be something you have to live with.
How about changing the caching query for the itemset items to check the itemset_reagent table first to see if $setid already exists and if it does then not save the items to the table once again?
To be perfectly honest, I don't really see what the big deal is. Its a few extra bytes of DB storage, and does not interfere with the execution of the script. The only way I would be able to make it work properly would be to completely redo the reagents table and I have other things to fix/improve/write at the moment.
On a side note, I am going to be writing an armory tooltip script similar to this one, except that it would use Wow's armory to get the information. It will also use an AJAX Javascript file to parse links as you mouseover them, similar to how Wowhead's power.js file works. Obviously, I won't be talking about it as much on this site, given that it doesn't use Wowhead. I'm thinking I may release them as a Wow package, should be pretty damn cool.
Its not a big deal, beyond looking stupid and incorrect. And while the script continues to run, it displays the information incorrectly.
Once this has occured, ever single time you link a set with or without the hero prefix you get double entries for ever single item in the set.
I use the exisiting wowarmory mod to provide armory data via links but I would appreciate an all in one package and look forward to that.
I will be happy to fix the problems, it just may take some time while other issues get worked out as well.
@Beelzabud, thank you for pointing out the problem with the installation instructions. I hastily wrote them, and it appears that I left out an important step. =D
Publicado por
94362
This post was from a user who has deleted their account.
Publicado por
91920
This post was from a user who has deleted their account.
Publicado por
293107
This post was from a user who has deleted their account.
Publicado por
91920
This post was from a user who has deleted their account.
Escribir respuesta
Este hilo está cerrado. No se puede escribir una respuesta.
