nyodulf

I was having the same issue with another plugin, and the ini_get() solution didn’t work. However, WP’s own get_temp_dir() did work.

I don’t know if there is a reason not to use the built-in function, but it worked for me.

@esmi: I do apologise, but that’s not what happened. I had posted a suggestion, but I’ve been up working all night and didn’t realise that my suggestion was negated by info in the OP. My ‘nevermind’ was me editing my post. I would have deleted it if it were possible.

nevermind =(

Further to the bug report, clicking on “Dismiss” in the big Welcome message causes an error. The error messsage suggests posting an issue on Github, with a link. The link goes to a 404.

One thing this plugin desperately needs is some kind of accurate reporting on its successes and failures. It will happily tell you that it has created a backup when in fact it has not. This can be caused by permissions problems for example.

It will do the same for renaming the wp-content folder, though refreshing the page will show you that the folder is still called ‘wp-content’. But you have to look for it, because the message reports success.

Are you using Better WP Security? If so, check if Display random version number to all non-administrative users is checked under ‘Tweaks’. If it’s checked try unchecking it – that solved this problem for me.

Yoast has a check for valid facebook locales when using the function above. Yoast will default to ‘en_US’ if the ‘return’ value is not in this list:

'ca_ES', 'cs_CZ', 'cy_GB', 'da_DK', 'de_DE', 'eu_ES', 'en_PI', 'en_UD', 'ck_US', 'en_US', 'es_LA', 'es_CL', 'es_CO', 'es_ES', 'es_MX',
'es_VE', 'fb_FI', 'fi_FI', 'fr_FR', 'gl_ES', 'hu_HU', 'it_IT', 'ja_JP', 'ko_KR', 'nb_NO', 'nn_NO', 'nl_NL', 'pl_PL', 'pt_BR', 'pt_PT',
'ro_RO', 'ru_RU', 'sk_SK', 'sl_SI', 'sv_SE', 'th_TH', 'tr_TR', 'ku_TR', 'zh_CN', 'zh_HK', 'zh_TW', 'fb_LT', 'af_ZA', 'sq_AL', 'hy_AM',
'az_AZ', 'be_BY', 'bn_IN', 'bs_BA', 'bg_BG', 'hr_HR', 'nl_BE', 'en_GB', 'eo_EO', 'et_EE', 'fo_FO', 'fr_CA', 'ka_GE', 'el_GR', 'gu_IN',
'hi_IN', 'is_IS', 'id_ID', 'ga_IE', 'jv_ID', 'kn_IN', 'kk_KZ', 'la_VA', 'lv_LV', 'li_NL', 'lt_LT', 'mk_MK', 'mg_MG', 'ms_MY', 'mt_MT',
'mr_IN', 'mn_MN', 'ne_NP', 'pa_IN', 'rm_CH', 'sa_IN', 'sr_RS', 'so_SO', 'sw_KE', 'tl_PH', 'ta_IN', 'tt_RU', 'te_IN', 'ml_IN', 'uk_UA',
'uz_UZ', 'vi_VN', 'xh_ZA', 'zu_ZA', 'km_KH', 'tg_TJ', 'ar_AR', 'he_IL', 'ur_PK', 'fa_IR', 'sy_SY', 'yi_DE', 'gn_PY', 'qu_PE', 'ay_BO',
'se_NO', 'ps_AF', 'tl_ST'

Further to this, the widget works but the main list doesn’t update when using the template-based code.

One more try…

One thing the bulk uploader does not do, which the main plugin does, is hash the file and put it in the uploads/yyyy/MM/ directory, and I think this is the main issue.

The bulk uploader script uses the following functions on the files it finds:

• wp_insert_post
• wp_set_post_terms
• wp_check_filetype
• wp_insert_attachment
• wp_update_post

None of these will move the file to the correct place and hash it in the same way that the admin interface version does. Functions like filename_rewrite and rewrite_file_url are integrated into the wp_handle_upload process using ‘add_filter’, but don’t get a lookin in the bulk import version, so the plugin can’t serve the files properly.

Any chance of a working version of the bulk importer? I am using this plugin because of the response in this thread: https://www.ads-software.com/support/topic/can-i-ftp-files-to-the-server-and-get-wp-document-revisions-to-index-them?replies=3 but as far as I can tell it cannot work in its current form.

OK, some more info on this:

If I set the post status to ‘public’ in the importer, the result is a bit strange too – the posts don’t show up anywhere in the dashboard, but the number of posts under ‘All’ in the post counter continues to rise by the number of documents found by the importer. Basically, the importer seems to be capable of creating posts in the database to which there is no interface in wordpress – no way to view them and no way to delete them.

I’d really appreciate some help with this. I have to get this working for a client who has over 300 documents to set up, and obviously doing that manually for each one would take a lot of time. I am simply using the bulk importer as is, only changing the paths apart from that one experiment with the post status.

Bump!

In case it wasn’t clear, when I said above that “Uploading a new version fixes it”, I meant that for any document with a broken permalink, if I upload a new version of the document through the admin, it fixes the link, but obviously that isn’t much use with a bulk importer.

The way the importer is written, it implies that the documents folder for import can be anywhere. Is that the case? In general it would be helpful to have a bit more info on what conditions are required for the bulk importer to work.

One fix is to add wmode='opaque' to <embed> element

Just to clarify: Does that mean that wp_dequeue_style cannot be used to remove the default jquery css?

For myself, rather than disabling the existing css (as the topic of this thread suggests), I would prefer a simple method to override it. Ideally it would be as simple as placing a stylesheet with a set name in the theme folder which EM would use to override any of its defaults.

I’d appreciate a more in-depth explanation of how to override it too. The head markup which calls the jquery css looks like this:

/* <![CDATA[ */
var EM = {
	ajaxurl: "https://(...)/wp-admin/admin-ajax.php",
	locationajaxurl: "https://(...)/wp-admin/admin-ajax.php?action=locations_search",
	firstDay: "1",
	locale: "",
	bookingInProgress: "Please wait while the booking is being submitted.",
	ui_css: "https://(...)/wp-content/plugins/events-manager/includes/css/jquery-ui-1.8.13.custom.css"
};
/* ]]> */

How do I override that?

Yes, I second that (I asked about it a few weeks ago but haven’t heard back).

Have you found a solution in the meantime, hanimausi?