Cyberchicken

Ok, thank you! It’s just an emergency tweak. I’ll keep in mind.

Hey, I was about to make the very same questions! ??

Could you please publish the answers?

Thank you

The token I got from the debug console expired, I created another one, but the whole thing escapes me: why don’t just I need a page id and a password?
Where should I document myself?

In the front I get “ERROR: An access token is required to request this resource.”
But no error in the back, it just reloads the widgets panel after trying to get the access token.

I managed to get the access token (still don’t know what it is) via that debug console you gave me, pasted into the widget config and now I can retrieve the events.
Still the button “get Facebook access token” doesn’t work.
How can I give you more details?

Thank you!

Maybe I don’t understand you observation, and maybe I’m ignorant as hell, but afaik each content object of wordpress is, by now, a “post”: pages are “posts”, portfolio items are “posts”, boats are “posts”, team members are “posts” and so on.
Just like in Joomla everything is an “article” (actually in Joomla pages are “menus”, but that’s even weirder).
Ok, this works but it’s not very clear by itself: a page is a page and a post is a post and a comment is a comment, and they all are some kind of “content”, right?

Now, I don’t expect this tiny bit of innocuos legacy to be fixed anytime soon, I just would like to know if it has been discussed before and, if possible, to discuss the drawback of an hypotetical change.

It’s quite clear that wem WP was a blog platform “posts” had their table named “posts”. Now everybody knows WP fights hard (and wins) to be a generic CMS, and this could be a tiny little step, but in the right direction. Question is: how much does it cost?
Thank you!

?? No, I’m not coming from Drupal, I got the clarifying suggestion from a tutorial about custom post types (which I lost), and _afterwards_ discovered that Drupal implements the same concept calling it “custom content”.
Anyway I’m not interested in standardizing nomenclature among cms (even if it is a very nice plus), I’m more interested in calling things with their name.

For example the third famous cms whose name begins with J invented an entire nomenclature on its own which could even be coherent, but is so hard to remember beacause it is so different from the rest of the world…

I came here to report the bug, but it’s already done.

Just in case someone needs the tip: activate the plugin, use it and the deactivate.

Please developer: ask us a hand if you have no time for fixing it. It would be a waste if everybody would fix the plugin on his own and not be able to redistribute the patch.
I took a look: I think the problem lies in lines 12-17 of db_prefix.php; I think they should be wrapped in a function and that function enqueued at the correct hook (I know the theory but never did it myself).

Thank you!

Gosh! Two days and I got the update in my system ??
Thank you!

With this patch of mine the default is already Passive on. I explicitly worked to have this. You will check.
I don’t think that the option will be needed to be registered in the wipe list because it ends up together with the oter ftp options, but you’ll have to confirm this.

I do state you have permission to include this patch in your code.
But please please please pretty please try to ship it with the next updates ??

Thank you David

Here is my patched version of file https://ftp.php

I’m quite satisfied, except for a small coding ugliness that you might help to sort. Nontheless I consider it production ready.

Re-enabling the already present passive functionality:
line 43 read:
if ($passive) $ftp->passive = true;
which works only if the default for passive option is false, which is not as we can read at line 10 of https://ftp.class:
public $passive = true;
therefore I changed line 43 to:
if ($passive) { $ftp->passive = true; }else{ $ftp->passive = false; }

Adding the option to the control panel:
<input type=”checkbox” id=”updraft_ftp_pasv” name=”updraft_ftp[pasv]” value=”1″ <?php if ($opts[‘pasv’]) echo ‘checked=”checked”‘; ?> /> <?php _e(‘Try disable if authentication is fine but cannot write file’,’updraftplus’);?>
the option itself (line 349 new version)
pasv: (jQuery(‘#updraft_ftp_pasv’).is(‘:checked’)) ? 1 : 0,
javascript linked to the test button (line 267 new version); very simple, I copied from the same function

This was sufficient to make it work, both test and uploading actual backups via ftp.

Saving the option to the db:
this was tricky because with the single <option> I could save in the db only a “1” or a no value (no key present).
I.e. I could distinguish blank/null/unset from “0” value.
(updraft_ssl_nossl instead has a record of its own and can be saved as both a “1” or “0”)
So I reminded an old trick to straighten up http post model for checkboxes and I added
<input type=”hidden” name=”updraft_ftp[pasv]” value=”0″ />
at line 348, just before value “1” option.
If the second input (checkbox) is not checked then the browser sends only one value (“0”) and the situation is super normal. If the second input is checked, then the browser sends two fields with the same name, in the specified order, with values “0” and “1”. Php then values the $_POST item with the last value sent by the browser, wich is going to be the value of the checked checkbox.
This way I can always save a value, wether “0” or “1”.
Afaik this little know “trick” is prefectly legal and has no drawbacks, but I think that the correct way should be a processing “normal” post options and saving correct boolean php types. I suspect that the saving part is undertaken by wordperfect, right? In this case I should discuss this with someone of their staff. Or is there already a way to specify that a particular option is a boolean?

Anyway that was not enough, because the default value in the populating code (function get_opts()) had to correctly distinguish a non-present value from the string “0” value. After consulting the web in general and this in particular, I chose to write
if (!isset($opts[‘pasv’]) || $opts[‘pasv’]===”) $opts[‘pasv’] = true; //dafaults to true

This way the default behaviour of the plugin is to have passive on at the beginning, just like before.

At this point I noticed that the same problem with “empty” could hinder also the values of username or password:
I made a simple test and actually a username or password of “0” cannot be correctly loaded from db: when the form is loaded “0” is misread as an empty value and the default ” is put in place. Yes, a very marginal case, but wanted to report it to you. You never know when an administrator will impose usernames like 0, 1, 2 etc…
I humbly suggest to change the test for an empty value to (isset || ===”).

Other modifications:
lines 15 and 22 are probably useless, but those the first modifications I did and understood what they might have been at the very last. I left them for simmetry. You will decide of course.

LInes 369 and 391 are of course needed to read the option value and execute the test with it.

I’d love to hear what you think.

Updraft has been uploading for the last 45 minutes now. It’s a bit long, but that’s not a problem, the resume works flawlessly. So for me is a success.

I’d really like to have it included in your code base so that I can use the ftp upload on that server no matter Updraft updates.

If you think I can post the patch on support forum.

Thank you for the software and your attention.

php.diff against Version: 2.9.60.0

14,15c14
< 		'path' => UpdraftPlus_Options::get_updraft_option('updraft_ftp_remote_path'),
< 		'pasv' => UpdraftPlus_Options::get_updraft_option('updraft_ftp_passive')
---
> 		'path' => UpdraftPlus_Options::get_updraft_option('updraft_ftp_remote_path')
22d20
< 	UpdraftPlus_Options::delete_updraft_option('updraft_ftp_passive');
45c43
< 		if ($passive) { $ftp->passive = true; }else{ $ftp->passive = false; }
---
> 		if ($passive) $ftp->passive = true;
59d56
< 		if (!isset($opts['pasv']) || $opts['pasv']==='') $opts['pasv'] = true; //dafaults to true
267d263
< 				pasv: (jQuery('#updraft_ftp_pasv').is(':checked')) ? 1 : 0,
347,351d342
< 			<th><?php _e('Passive','updraftplus');?>:</th>
< 			<td><input type="hidden"                         name="updraft_ftp[pasv]" value="0" /> <!-- provide an alternating value -->
< 				<input type="checkbox" id="updraft_ftp_pasv" name="updraft_ftp[pasv]" value="1" <?php if ($opts['pasv']) echo 'checked="checked"'; ?> /> <em><?php _e('Try disable if authentication is fine but cannot write file','updraftplus');?></em></td>
< 		</tr>
< 		<tr class="updraftplusmethod ftp">
369d359
< 		$pasv = $_POST['pasv'];
389,391c379
< 		//VITTO ISZ
< 		//$ftp = $this->getFTP($server, $login, $pass, $nossl, $disable_verify, $use_server_certs);
< 		$ftp = $this->getFTP($server, $login, $pass, $nossl, $disable_verify, $use_server_certs, $pasv);
---
> 		$ftp = $this->getFTP($server, $login, $pass, $nossl, $disable_verify, $use_server_certs);

Ok, I’ll post here the diff and the comments. Version is the latest. I’ll take note.

Sorry, I was a bit shy, I wanted you to review my modifications before spreading any potentally embarassing code ??
Let’s say that If I don’t hear anything from you in a few days I’ll post it here for everybody.

I did it! I’m SO satisfied!
I patched the plugin to allow passive ftp connections. It’s working for me and I put it into my production.

I’m writing privately with the file, all the comments and the hope that you’ll like it and include it in the next release of the plugin.

I’ve added this idea (active FTP support) to our request list…

Thank you David!

I wouldn’t get too hopeful that it might happen any time soon, though –

??

this is the first time it’s been requested, after 2 million downloads, so it doesn’t seem to be something that a lot of people are very interested in…

I already knew it, otherwise you’d already put the option there ??

I’d suggest trying another storage option in the mean-time – e.g. Dropbox is very easy to setup and has a free storage tier.

Yes, but the free version is not enough and the payed version is about six time more expehensive (and packs unneeded features) not counting the updraft addon ;). I’ll think about it.

Do you mind If I tinker with Updraft code? For me it could be well worth the effort, especially if you consider including the patch in future releases.
One thing bugs me: it looks like the option is already in the code, I only have to switch it!

Ok, a bit of refinement:
in wp-config.php
define('blog_public', '1' ); // option "discourage search engines" '0': checked true, '1': unchecked empty

in mu-plugins/config_blog_public.php

add_action( 'wp_loaded', 'config_blog_public' );
function config_blog_public() {
	if (defined('blog_public')) {
		if (constant('blog_public')=='0') {
	 		add_filter( 'pre_option_blog_public', '__return_false' );
		}
		if (constant('blog_public')=='1') {
 			add_filter( 'pre_option_blog_public', '__return_true' );
		}
	}
}

Now the “discourage” option is basically dead: whatever I check this plugin overrides it. I should find the way to “grey out” the option and add an explanation. (Any suggestion about where to look? ??

Note that if I don’t set the constant to ‘0’ or ‘1’ strings the behaviour is normal.
PS It really works: I can see <meta name="robots" content="noindex,follow"/> appear and disappear just by changing the option in wp-config.php

With a bit of more work I could release this as a complete reusable plugin.

Thank you!