project
project summary freshmeat entry development infos mailing list WebInstaller database tools ChangeLog
page plugins
ProtectedEmail PowerSearch README README.config README.plugins README.fragments ProtectedMode INTERNALS WordIndex AboutPlugins PhpInfo OrphanedPages ListOfPluginHooks RSS RecentChanges PageIndex NewestPages SearchPages MostVisitedPages MostOftenChangedPages UpdatedPages
usage hint
9OTUNE YOGURT SÜREER AYRAN OLANA KADAR SİKERİMxD
BUG#8177 integration with wordpress
| ver | R1.01e |
| os | Unix |
| db | mysql |
| php | 4.3.x |
lisah2u: A couple of strange things...
1. When I click on the preview button I get a SQL error:
Database error: *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 ')' at line 4 SELECT DISTINCT ID, category_id, cat_name, category_nicename, category_description, category_parent FROM re_categories, re_post2cat, re_posts WHERE category_id = cat_ID AND post_id = ID AND post_id IN ()
Warning: Invalid argument supplied for foreach() in /wp-includes/functions.php on line 1728
Database error: *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 ') GROUP BY ID' at line 4 SELECT ID, COUNT( comment_ID ) AS ccount FROM re_posts LEFT JOIN re_comments ON ( comment_post_ID = ID AND comment_approved = '1') WHERE post_status = 'publish' AND ID IN () GROUP BY ID
Database error: *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 ') ORDER BY post_id,meta_key' at line 3 SELECT post_id,meta_key,meta_value FROM re_postmeta WHERE post_id IN() ORDER BY post_id,meta_key
2. Image uploading doesn't work properly. The link is created and image metadata is present and there is a new entry in the MSQL database. However, it appears that the image file is prefixed by html from the wiki so that it is a mix of text and binary information. So, of course, the browser sees a corrupted file.
Update - Sorry figured out the problem to problem (1) by reading your README more carefully. This was an easy fix. Still haven't figured out how to fix (2)...
BTW, great job on this wiki. I've been trying out tons of wiki software and finally settled on this as being the most configurable and flexible.
Andy: For 2, you should check that ewiki.php is included before _any_ of your template page's text. A loose carriage return has ruined my image loading many a time. Similarly, but not critical to images, ewiki_page() should be called before any page text for best results.
MarioSalzer: To 2nd: You have incorrectly inlcuded() ewiki into your site. The <html> that prepends the returned image binary data is from *WordPress I'd say. There are two possible solutions.
The recommended way to embed ewiki fully is to put the 'include("ewiki.php");' as the very first command in your page template (may be neccesary even before any wordpress-includes are called, because those are occasionally emitting html already). This will also provide you with the full ewiki HTTP power.
Another workaround was to use 'fragments/binary.php' (notes in there), but this is rather sub-optimal.
-
- To 1st**: This looks like *WordPress DB database access commands, so may not
be at all related to ewiki. What I could guess is that some of ewikis POST variables interfer with parameters *WordPress expected (a "varaible name clash" if you want). Suddenly ewiki is not yet very configurable at this point (we have *EWIKI_UP_ constants everywhere else to prevent such things). The longer I think about this, the more clear it gets that only the *preview in ewiki somehow makes *WordPress think that their comment *submit/preview was triggered (however this then also suggests, that WP isn't very clean in environment and parameter checking).
To quickly fix this yourself you needed to edit 'ewiki.php' and change one occourence of '$_REQUEST["preview"]' and one of 'name="preview"' with let's say 'ew_preview' to make it distinguishable.
I now also put it on our todo list to give those parameter/var names more ewiki-specific names per default in the next version...
lisah2u: The image problem was fixed by ensuring that ewiki.php was included in my config file. It didn't work when the include was at the very top of my main script. It's very sensitive, apparently. The preview fix worked partially. There are now no more sql errors. But I actually don't see a preview now, while before I did (+ sql errors). I'm very curious if this
makes sense to you!
milky: Not much, indeed. Have you double-checked, that you also changed the $_REQUEST["preview"] var accordingly? Else simply try another string name for both occourences. And please don't use "ewiki_preview" - which could be stripped out by fragments/strike_register_globals.php in case your PHP version is a bit older (or misconfigured respectively).
If including() ewiki.php at the top of your main script didn't work, then some of the *WordPress includes really throw out random html tags before (maybe just a <!DOCTYPE> or something like those silly comments as seen elsewhere).
lisah2u: Yes. I double-checked. I used "ew_preview" as suggested in both places. I'm still scratching my head on this but it's not a major problem.
Here's another one: I've been struggling to implement auth-liveuser. I'm in the portion of the task where you execute livuser-setup.php. I don't have commandline access on my host, but managed to execute this on my localhost machine and view the php output. Now I'm trying to get this to work on the remote server from the browser and get: Fatal error: Call to undefined function: setfetchmode(). Pear DB is installed and there is no problem with the require_once statement for "DB.php". I tried turning register globals on in the auth-liveuser directory to no avail. I don't know much about php, so I even tried a require_once on "DB/common.php", but got the same error. Is there a work-around or does this make any sense to you? Would there be any difference running this via commandline versus in the browser?
Andy: I have encountered the same problem, mine I traced to an old or missing PEAR:DB package. Register global is absolutely unneeded. You can try disabling that line, that particular call is probably uneeded and the following error may be clearer. You should note that $liveuserWikiDB needs to be a connection to your EWiki database, not your LiveUser database.
lisah2u: By commenting the line you suggested, I managed to get through the setup file to the point where the mySQL records were created. But when I run things in the browser now I get this error: Fatal error: Call to undefined function: gethandle() from auth_liveuser.php. This just doesn't make much sense...
UPDATE: I gave up on using my webhosting service for pear and included all of the pear files locally under the liveuser directory, added the appropriate php include path info. No more errors reported from the web browser, but now when I access the site I get a completely blank page. I will try removing the DB and starting over with all local pear packages.
Andy: Ayup, that's what I did too, I'm less than completely sure about the pear version requirements, but I went with a local. You should run ewiki once without the auth plugins as part of the setup is adding default rights to extisting pages. If that isn't done for the main page you *should* still get an access denied message but the situation is disfunctional so that maybe what you are/will run into. There's also a die call if the "liveweb_login_log" table is not available, but that should give you a message. You may wish to disable that section of code though a rate limited does wonders in quantifying and limiting risks, especially from password guessing attacks.
lisah2u: Yep. I discovered the missing table and tried to run that code. There was a syntax error in some mysql code (missing paren) and some discrepency between liveweb_login_log and liveuser_plugin_login_log. I actually did a couple small bug fixes and, finally, disabled some of this code and got the plugin to run sort of. It chokes when there is no user specified -- user name is 'Array'. And, when I specify user1 for username and pwd, it says I'm not authorized to view the page. So something is still buggy but I don't know exactly what at this point.
Andy: I think I missed this post when you first put it up, sorry for the delay. Could I get you to send your modified code and a database dump (censored if you need to) to me?
