Forum Replies Created

Viewing 15 replies - 76 through 90 (of 181 total)
  • Great! Do you have any idea of what the problem was? Or no idea, just pleased it works now?

    Sounds like a memory or time out issue. You should contact your host about how to temporarily increase the PHP memory_limit and/or max_execution_time.

    Forum: Plugins
    In reply to: [WordPress Importer] Broken

    Sorry, I’m not quite sure what the problem is.

    Are you having issues when running the import? Or when editing imported posts/pages? Or when making completely new posts/pages?

    If it’s the last of the three I don’t know how it’s related to the importer plugin. A short list of the steps that you made up until the problem occurred would be best.

    Thanks.

    Are the image tags completely missing or are the contents of the title attributes missing? Or something else completely?

    If you switch to HTML view in the editor on a post which is supposed to have an image what does the HTML img tag look like if it’s there? What exactly is wrong about it, some examples of before and after import.

    Problem #1 sounds like memory or time limit issues. Having you tried defining WP_DEBUG as true? If you’re able to get hold of some error logs they might shed some light on the cause.

    Plugin Author Jon Cave

    (@duck_)

    Done, sorry for the delay. Update notifications should be visible in dashboards soon.

    Sorry that this was not more obvious to you.

    The WordPress export functionality does not aim to be a full back up of your site, just a good way of exporting content. If you take a look inside the file it will tell you more in the comments at the top. The list of content you’re told that will be exported does not include options.

    Maybe stating this even more clearly, using the same terminology as found in the export file commetns, is required in the Help dropdown for example.

    Thanks for the extra info. I will look into it.

    As lloydbudd says that fatal error indicates that the importer plugin has been loaded twice. This used to occur as a bug if the script died during the plugin activation hook, but after the plugin had been added to the active_plugins option. Firstly this was fixed in 3.0.2/3.1 and second the importer doesn’t do anything on the activation hook.

    Currently the only other way I can think of this happening if there is another plugin hooked into activated_plugin (or a similar action) which is causing the script to end after the importer has been added to the active_plugins array.

    You could try deactivating all other plugins and then activate the importer to see if there’s a difference. Or manual activation by adding to the active_plugins option and checking for a fatal error (as this one requires database manipulation of a serialized field I wouldn’t recommend trying it on a production site or if you’re not confident enough).

    The notice is showing when the importer trying to create the post because i have added the update_post_meta() to the action “save_post”

    You should check isset( $_POST['price'] ). The importer doesn’t have a form for the price so the post data isn’t set; I would think the same kind of thing would happen with QuickPress on the dashboard too.

    If the meta problem nothing to do with importer then still the importer does not importing any post meta.

    Post meta is imported from the contents of the file. In the post <item>s you will see <wp:postmeta> tags which hold any post meta stored for a post.

    When i am in media library. Every media is shows the post name with which it is attached to right? The attachment info obtained when any media placed/inserted in the post.

    But in wordpress you will notice if you upload any media via the uploader and not inserted to the post it still got attached to the post. In this case the media/image is missing the parent info.

    Still not entirely sure what you mean by this. Could you give me an example of what’s wrong. So, row in the database before export, <item> in the export file and the row in the database after importing (double checking that any IDs, e.g. post_parent, are pointing to the correct post). This might be a lot of info. so could you either put it on a pastebin website (e.g. pastie.org) or email it to me.

    If you could provide an example export file that isn’t working correctly for you that would be great. Email: wp {AT} lionsgoroar.co.uk

    Edit: Sorry think I’ve got it now: Imported media isn’t showing which post it’s attached to on the Media screen -> “Attached to” column after importing to a new site.

    I am unable to reproduce this myself so sending me an export file that doesn’t work for you would be the best course from here… see above.

    The post meta problem sounds like it has nothing to do with the importer. Without seeing the code I cannot say for sure (I guess it’s a custom theme as I couldn’t find it in the repository). My guess is that the theme is calling update_post_meta on every page load but $_POST[‘price’] is not set on every page load and so there is the notice (it also sounds like poor security as anybody could set $_POST[‘price’] and get information stored in the database).

    Could you explain the media problem a bit more? Are you saying that the images or whatever are being uploaded and can be seen in the Media menu, but they don’t show properly in posts? Could you give me a link to a post showing the problem? Is this occurring after you have tried to use the wordpress-importer plugin to importer a WXR XML file?

    Yeah it’s really weird and inconsistent like that. I’m leaning towards thinking that it’s something to do with small file batch sizes as that is an error message caused by a failed AJAX request. Thinking that it might be trying to work too quickly. You might want to try increasing the “number of files per batch” for a scan and see if that helps.

    Plugin Author Jon Cave

    (@duck_)

    Actually will try increasing the default “Number of files per batch” for fewer and less frequent DB hits.

    Plugin Author Jon Cave

    (@duck_)

    Thanks. Guess there’s not much to be done about it then apart from fail gracefully and ask the user to try again later.

    Sounds like a configuration issue to me. That error is generated internally by PHP (UPLOAD_ERR_NO_TMP_DIR), it means that PHP doesn’t have a temporary directory to store uploads before they are move to a permanent location. Surely adding media items doesn’t work either (Media > Add New)?

    You’ll need to speak to your hosting provider about fixing this.

Viewing 15 replies - 76 through 90 (of 181 total)