Jon Cave
Forum Replies Created
-
Is the first one cause for concern?
Possibly yes. The scanner only looks in core files if they have been modified. However, I notice that you’re seeing class-ixr.php whereas that file is called class-IXR.php in 3.1 and the line that got highlighted was changed between 3.0 and 3.1 to remove the
trim. So looks like something weird has happened there, although that line is fine.The second one is just a comment, so I don’t know why it’s been flagged.
The scanner doesn’t make any distinction between file type, comments, etc. And php.ini isn’t a core WordPress file.
I tried Exploit Scanner 1.0, and the missing hashes message is gone now. Thanks for fixing that!
No problem, and thanks 🙂 I try to get hash updates out within hours of a WordPress release but just delayed a bit this time for other reasons.
There are 13 severe messages, mostly eval messages, some base64_decode messages. Is this normal?
It depends on your choice of plugins — I assume some of the other plugins you are running are being flagged. I don’t have anything like that picked up on my installs except for testing the scanner.
All matches have to be interpreted in context. Those functions can be used for non-malicious purposes (otherwise they wouldn’t be provided by PHP!), but they are very common in malicious code which is why the plugin searches for them. If you have the understanding to look through at the plugin code (something I would do for any plugin I install) to see how these functions are used then it’s safe to ignore that output and use it as a baseline. If you’re seeing matches in modified core files or in previously unheard of locations (maybe hidden away in an innocuous file name in wp-includes) then you should be more worried.
A new release for WordPress 3.1 will be coming shortly. Just waiting to see if I could track down and fix a bug others have been experiencing.
Forum: Plugins
In reply to: [Exploit Scanner] Exploit Scanner errorsWould you be able to try out the development version (see details above) which should be version 0.99.2 now.
Could you also tell me what other plugins you’re running? And any other details about your set up could be useful. It’s so frustrating that I can never reproduce this!
That’s strange and it’s not happening for me (e.g. getting uploads in 2010/08 and 2011/01 for the latest theme test data).
The file should be saved using the post date specified for a particular attachment in the export file. Take a look at the XML and search for one of the attachments that’s in the wrong folder and check the
<wp:post_date>tag.Forum: Alpha/Beta/RC
In reply to: 3.1-RC2-17330 doesn't adds extra classes to commentsWith 3.1 exports we can now at least correctly identify comments made by users with posts but the problem would still remain for subscriber comments.
WordPress Importer 0.4-alpha2 now has this ability (NB: as mentioned above currently only for users in the export file, i.e. those with posts).
In about 10 minutes you can try the development version which has had a fix applied. It will show up as version 0.4-alpha1 in your plugins page and it is available from the other versions download page (or use this direct link to the zip file).
If you are able to test it out to confirm it works I would appreciate it.
Thanks again for reporting so quickly!
Confirmed. Thanks for reporting, will fix shortly.
The old version is available from the other versions download page.
Forum: Alpha/Beta/RC
In reply to: 3.1-RC2-17330 doesn't adds extra classes to commentsUnfortunately it is a problem with the importer which doesn’t import exported user IDs associated with comments. I believe the reason this wasn’t implemented is because these IDs will not reference the same user on the new site you’re importing to. Missing information is better than incorrect information.
With 3.1 exports we can now at least correctly identify comments made by users with posts but the problem would still remain for subscriber comments.
If you need the correct user ID with a comment then I imagine you’ll also want the subscriber users in which case I recommend using SQL dumps for now.
Forum: Plugins
In reply to: [WordPress Importer] [Plugin: WordPress Importer] Issues in wp_postsThe guid field represents a unique identifier for a post (typically useful in RSS feeds AFAIK) so it shouldn’t matter if it’s referencing an invalid address. The only reason that it uses what looks like a permalink/shortlink is because that makes a simple, relatively good unique (and permanent) identifier. However it should NOT be treated as a URL or permalink (note that the guid element in the export file states that it isn’t a permalink in the isPermalink attribute).
However there was some argument on http://core.trac.wordpress.org/ticket/6492 for updating/changing the GUID on import in case of duplicating the ‘unique’ field.
Forum: Fixing WordPress
In reply to: Blog import not workingHi sjalle.
What about file_uploads in php.ini?
If this doesn’t help could you please open a new thread instead of continuing this one.
Thanks.
P.S. it sounds like you are exporting a lot of data, I would actually recommend database dumps (e.g. mysqldump or via phpmyadmin) for such large backups and imports if possible.
Thanks for the report.
There is already a ticket about this on Trac http://core.trac.wordpress.org/ticket/16445.
Forum: Plugins
In reply to: [WordPress Importer] [Plugin: WordPress Importer] comments missingOkay, glad you got this sorted 🙂
Forum: Plugins
In reply to: [WordPress Importer] [Plugin: WordPress Importer] comments missingA previous version of WordPress shouldn’t make a difference; especially if you have upgraded within the 3.0.x family.
You could try out the vastly improved development version [direct link] of the importer available from the Other Versions page. Though I have had no previous problems when importing comments using version 0.2 of the importer.
Having access to a sample export XML file that does not work for you would really help to diagnose the issue. If this is possible you can contact me privately via email:
wp {AT} lionsgoroar.co.ukForum: Fixing WordPress
In reply to: Blog import not workingFor those following along there was nothing wrong with flourishrob’s export file. Then I re-read this:
Yesterday it got to 69 before saying ‘Done’ in my browser window. Today it got to 79. I would expect some sort of,’you’ve updated, click here to continue’ or something, but it just… stops.
This definitely sounds like the PHP script is hitting the max_execution_time set in the server’s php.ini. If I am correct this probably means that the host is running PHP in safe mode (deprecated PHP 5.3, but that’s another story) since the importer tries to bump the execution time using set_time_limit.
Replying to fpol:
If I open the XML file with an editor, I see the tags but no post content(should I even see the content here?) I have tried the WP exporter, but I don’t have an export button on the page. I used the Advanced Export plugin to even get this far. Everything else sounds exactly like what’s happening to flourishrob. Hope it’s ok to join on this post for help since it sounds almost the same. If not I can start a new one for myself.
This isn’t the same problem and you should start yourself a new thread probably in another forum section since you seem to be having trouble generating a useful export file. Yes you should be able to see post content in the XML file (all posts are held in
<item>tags). I have no idea why the built-in WordPress export page isn’t showing you the “Download Export File” button. Assuming you’re using WordPress 3.0.5 (and you should be!) the functionality of the built-in WordPress export is the same as that of the Advanced Export plugin.