ianatkins

Hi @ckadenge

Thanks for the reply. I’d reviewed the TOS page before posting and couldn’t find the answer.

We manage 20+ WooCommerce sites for clients – so updating this is non trivial. Would like some clarity as it affects how we’ll handle the updates and whether they are within the remit our support agreements.

As there is a post about this update pinned to the top of the forum, would hope this is the relevant place to discuss the update. ( https://www.ads-software.com/support/topic/updated-requirements-for-stripe-plugin-mid-2024/ )

Also in the name of transparency would think it would be beneficial to be clear if Automattic does earn referral fees from the plugin. ( Note, I’m not saying that’s a bad thing, as it obviously supports the development of the plugin ).

Thanks,

Ian.

Hey Michael.

Sorry let me try and clarify. When triggering a ‘re-indexing’ from the ‘autocomplete’ page, after an index has previously been created, the plugin individually deletes every record one by one. This is very slow compared to the first initial indexing when the plugin is freshly installed.

I don’t understand why the plugin doesn’t just call the ‘clear’ method to delete the entire index – and then just push the records in batches.

Perhaps the ‘reindex’ function ( and deleting an individual record ) is used ( and makes sense ) for the content syncing, but it doesn’t really make sense when manually re-indexing, where I think it’s safe to assume the whole index can be dropped as it is being remade.

It looks like this how the re-indexing works via CLI – so just not sure why it’s not the same when triggered via WP-Admin:
https://github.com/WebDevStudios/wp-search-with-algolia/blob/fe6fdbec5fe254c3f4e278729bb7921e0247290b/includes/class-algolia-cli.php#L118

Hope that’s clearer!

Hey Michael.

Thanks for the reply.

To clarify, I’ve only just installed the plugin – so always running version 2.8.1

Seems upon the initial install, and initial index the process is fast and in the Algolia logs, can just see batches of updateObject requests ( 100 records at a time ).

When running the re-index again, looks like the check for ‘records’ is always true in class-algolia-searchable-posts-index.php – so on the Algolia logs I just see several deleteObject requests with a single ID at a time ( example below ). This takes a very long time to process with 90K records.

Line where ‘records’ is checked:
https://github.com/WebDevStudios/wp-search-with-algolia/blob/fe6fdbec5fe254c3f4e278729bb7921e0247290b/includes/indices/class-algolia-searchable-posts-index.php#L373

{
  "requests": [
    {
      "action": "deleteObject",
      "body": {
        "objectID": "808-0"
      }
    }
  ]
}

If I delete the meta fields ( which makes that check in class-algolia-searchable-posts-index.php return false, then the index batches again and updates 100 records at a time.

Yeah i’m not using algolia_should_wait_on_delete_item filter.

Thanks,

Ian.

• This reply was modified 3 months, 2 weeks ago by ianatkins.
• This reply was modified 3 months, 2 weeks ago by ianatkins.

So have managed to get it batching quickly by bulk deleting the meta records with the name algolia_% – which is set from set_post_records_count

Not sure if this is just me – but perhaps there should be a ‘drop index’ option that does this and re-indexes from a clean slate, or the individual delete statements could be optimised with a clear at the start of the process.

I received an email from [email protected]. Might want to subscribe to the developer mailing list on page below:
https://developer.woocommerce.com

We’re reaching out to let you know that an important security update has been released for an extension installed in your WooCommerce store: Stripe for WooCommerce (also known as WooCommerce Stripe Payment Gateway). This update corrects 32 unpatched versions (from 4.5.4 to 7.6.0). The current, most up-to-date version of the extension is 7.6.1.

This update addresses a vulnerability that could have allowed bad actors to trick authenticated users with enough permissions to change the Stripe API keys associated with their store. 

We have no evidence that suggests this vulnerability was exploited. The vulnerability was originally reported via Automattic’s internal HackerOne proactive security program, and our engineering teams immediately developed this security update for you.

Hi @wfpeter,

There’s too many files, and they definitely part of core WordPress.

Have sent the diagnostic report.

Thanks,

Ian.

Ok have it working, but via PHP filter ‘block_type_metadata’

/**
 * Gutenberg : Edit block metadata
 */
if ( ! function_exists( 'addedlovely_edit_block_metadata' ) ) {
	function addedlovely_edit_block_metadata($metadata) {
		// Center core/paragraph
		if ($metadata['name'] == 'core/paragraph') {
			$metadata['attributes']['align']['default'] = 'center';
		}		
		return $metadata;
	}
}		
add_filter('block_type_metadata', 'addedlovely_edit_block_metadata', 10, 2);

Would be great if someone can confirm if this should be possible via theme.json

Thanks. That has no effect either, note I’m trying to apply this to core/paragraph block.

I’m not sure you’re correct about theme.json not affecting core blocks, as I can turn off the colour and background colour options on the core paragraph block. Perhaps just align and/or attributes are not supported – can’t see either listed here:

https://developer.www.ads-software.com/block-editor/reference-guides/theme-json-reference/theme-json-living/

• This reply was modified 1 year, 10 months ago by ianatkins.

@faisalahammad Thanks for the detailed reply.

Have updated and that doesn’t work either. Have tried in both the style and settings top level nodes.

Here’s what I’ve got in a reduced test case:

{
	"version": 2,
	"settings": {
		"appearanceTools": false,
		"blocks": {
			"core/paragraph": {
				"attributes": {
					"align": {
						"type": "string",
						"default": "center"
					}
				},
				"color" : {
					"background" : false,
					"text" : false
				} 
			}
		}
	},
	"styles": {
		"blocks": {
			"core/paragraph" : {
				"attributes": {
					"align": {
						"type": "string",
						"default": "center"
					}
				}
			}
		}
	}
}

@chouby Polylang Pro and free user here. Just re-evaluating SEO plugins and also would like to move to RankMath. It seems more developer friendly with multiple hooks / filters and less upsell for clients than Yoast.

Definitely seems like it fits your market ( presumably developers or technical users ) more than Yoast.

Seems like a popular idea and would love to see it added.

@contentiskey Hey Lisa, there’s no reference to alignment that I can see in either of those linked doc’s. Believe the property would be ‘align’.

I’m also curious as to how a default alignment can be set on blocks via theme.json.

Have checked here too:
https://developer.www.ads-software.com/block-editor/reference-guides/theme-json-reference/theme-json-living/

Isn’t a 100% clear but reads like this isn’t yet possible?
https://github.com/WordPress/gutenberg/issues/44007

Hi,

Thanks for the update.

Just to check did you receive my emails to support@ regarding this, as had no reply there?

Best.

Ian.

Would also like to know the reason for closure.

Yes to cache the api responses, but not to serve stale content.

Let me know if litespeed won’t do this.

Hi Qtwrk

Thanks for the update, before I test that – do you mind confirming how that would work. Would the API request still get refreshed when new orders come in, with the force cache option enabled?

Would I also have to add one line per query string for them to be unique?

Will check our plug-ins in the interim to see if I can spot where that no cache is coming from.

Thanks,

Ian.