George

For the sake of clarity, i figured out that Gutenberg would not load due to REST API Toolbox (https://www.ads-software.com/plugins/rest-api-toolbox/).

This plugin has an option to remove the API endpoints and we had the pages endpoint removed. Disabling this plugin allowed Gutenberg to load on Pages.

This doesn’t alter my views and suggestions about Gutenberg.

• This reply was modified 6 years, 7 months ago by George.

As it stands Gutenberg is a REACT override of the current editor and not the other way around.

That’s good to know, i don’t think this is properly communicated.

I would still prefer to not include its files (around 90 at the moment) every time a php page or script is called, which is why i proposed to keep it as a plugin. WP comes with the hello dolly and jetpack, so why not pack pre-pack gutenberg but keep it separate to core and optional?

I don’t object to adding guttenberg, but as you say it should be an option that enables it only is the admin selects it on the writing settings. It should be disabled on people who upgrade and could be enabled for new installs.

• This reply was modified 6 years, 7 months ago by George.

My point is: Why are we forced to override/disable a feature of core WP?

In my opinion, WP should be as lightweight as possible and modular. Most stuff should be added as plugins by whoever needs them. Legacy support should also move into a plugin.

I don’t see why they need to force a new feature that A LOT of people will then disable. Instead, they could make it optional and just guide as many as they can to the new plugin.

Imagine one day they decide to force WC into core. You can argue that by having WC into core, anyone can produce revenue for everyone. We use WC in all our sites, but is this necessary for everyone? No, so you make it optional.

Why not do the same with gutenberg, especially after seeing such negativity from more than half the people who reviewed it? (2.4/5 currently)

The Gutenberg team is recommending this approach

Yet another plugin to install…

This definitely doesn’t add more code on each page load.

So you’re saying the Classic Editor is preventing the php files from being included? Looking at its source code i see a lot of remove_action and remove_filter but as far as i can tell, the actual includes from gutenberg are still there, just not used. No?

I saw your initial comment, but if i were to use this, i’d need to add a new location record for every city and town we’d like to use, no?

I see why you’ve added this feature and it’s great to be able to customise the display of SOME major cities, but when you add venues in bulk, you can’t keep adding them on the predefined locations section.

The way i see it, you could have an extra field for city with user input, similar to the postcode. You can then display it on the front end and use it for auto-suggest.

Then optionally, if this field matches the predefined locations field, you can link the venue with that predefined location.

Yes i know, but the first example, should be written as
Address 1: SU 8-11, Victoria Place Shopping Centre
Address 2: 115 Buckingham Palace Road
Postcode: SW1W 9SJ
City: London

This is the cleanest way of saving it and the one used by the majority of applications storing the address.

Is there a particular reason why you think you shouldn’t have the city as a separate field?

The Directory Locations is not what i’m after.

on Edit Listing -> Listing Locations you already have Address 1, Address 2 & Postcode but there should also be either a city or an Address 3 field. so we can fit the full address.

Many countries including the UK have the following address format

Address 1
Address 2 (optional)
Address 3 (optional)
City
Postcode
County/Province
Country

See the following address examples
* SU 8-11, Victoria Place Shopping Centre, 115 Buckingham Palace Road, SW1W 9SJ, London
* 31-34, The Arcade Lower Ground Floor, Westfield Stratford City, E20 1EH, London
* Swansea Morriston Hospital, Heol Maes Eglwys, Morriston, Cwmrhydyceirw, Swansea, SA6 6NL
* Edinburgh Airport Airside 1, Terminal 1, Edinburgh Airport, Ingliston, Edinburgh, EH12 9DN

Great, that solved the issue. Thanks.

Thanks for the reply. Can you overidde the JS the same way you override CSS?

To answer my own question, those suggestions can be disabled at “Search settings” -> “Search settings” -> “Enable locations search” or updated at “Directory Listing” -> “Directory categories”

Hi this appears to work fine on the latest version so i’ll close this ticket.

Thanks for the prompt response

Hi,

It seems to be working fine so far. I’ll keep an eye on it for the rest of the day and mark as resolved.

Thanks, i’ll test now.

Where’s the main repo for this plugin? The one on github doesn’t have the most recent changes

Hi, i noticed on the order confirmation emails only. It wasn’t happening for all transactional emails sent

Also,

In a slightly unrelated topic, your plugin appears to write two records on the wp_options table for each session it creates. When used on larger sites, this could be troublesome, as wp_options is a core table and almost every plugin reads and writes from it at least once on every page load, resulting in a large number of queries on each page load.

When the sessions are deleted every hour, depending on the SQL table settings (InnoDB/MyISAM) it’s likely the table will be locked until the delete query finishes.

It would probably be preferrable to store the sessions in a new table. This approach is already implemented by WooCommerce and works great, as there is only one record for each session, which keeps things compact and doesn’t spam the core tables. Furthermore, using a simple query, you can identify and delete old sessions in the event the cleanup is not working correctly, or like in our case, you have more sessions created each month, than your default cleanup settings can remove.

I would therefore urge you to consider moving the session storage outside wp_options and onto your own table.