studiopress / agentpress-listings Goto Github PK

The following message is displayed on plugin activation only with debug enabled:

The plugin generated 211 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.

Functionality is fine.

Hello.

This is a suggestion in order tu use the 4.4 srcset data for images.
I have noticed that the images used in the widget area placed in the sidebar are not optimized (loaded bigger than scaled down).

My suggestion is to use change:
$loop .= sprintf( '<a href="%s">%s</a>', get_permalink(), genesis_get_image( array( 'size' => 'properties' ) ) );
to:
$loop .= sprintf( '<a href="%s">%s</a>', get_permalink(), get_the_post_thumbnail( $post_id, 'properties', array( 'class' => '' ) ) );

What do you think?

When using WP_DEBUG the search widget shows undefined index errors.

Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'AgentPress_Listings::admin_style' was given in demos/wp-includes/plugin.php on line 470

Remove this from class-listinngs.php

add_action( 'admin_head', array( $this, 'admin_style' ) );

Left over from d1a23aa

Request to add Archive Settings page for the Listing CPT to be able to include a sorting option for the listing search results. This is a very common request on the StudioPress and other support forums:

Sort by:

Price - asc or desc
Date - asc or desc
Random Order

@rrennick mentioned this on the dev call. AP customers are not receiving notifications that an update is available. cc @nathanrice

Allow specification of Featured Image size in the AgentPress Listings widget instead of returning full-sized image.

Users often request two options for the Featured Listings widget:

• Sort by something other than date (typically a taxonomy term, such as price)
• Filter by taxonomy (so that listings that match a given selection of taxonomy terms are visible)

As reported on WP.org, the selected taxonomies are lost when viewing search results such as this:

http://demo.studiopress.com/agentpress/?s=&post_type=listing&bedrooms=4-bedrooms

Observed behaviour: No value is selected in the “Bedrooms” select field.
Expected behaviour: “4 bedrooms” (the originally selected query) is preselected in the “Bedrooms” select field.

Adding global $wp_query; near the top of the widget() function in agentpress-listings/includes/class-property-search-widget.php fixes this in my tests.

Instead of outputting classes "property-details-col1" and "property-details-col2" - should we change this to use the column classes built into genesis?

cc: @bgardner

The _listing_price_sortable key is being removed when saving a listing:

https://wordpress.org/support/topic/version-1-3-2-removing-meta_key-_listing_price_sortable/

Impact

New listings and edited listings may fail to appear in search results, archives, or other lists if _listing_price_sortable has been used in the query to select or order them.

The paid plugin Extended AgentPress Listings Widget apparently allows sorting by _listing_price_sortable, for example.

To reproduce

1. git checkout 1.3.1
2. Create a listing with a price.
3. Confirm the saved listing has a _listing_price and _listing_price_sortable:

❯ wp post meta list 7488
+---------+-------------------------+--------------+
| post_id | meta_key                | meta_value   |
+---------+-------------------------+--------------+
| 7488    | _edit_last              | 1            |
| 7488    | _edit_lock              | 1562778936:1 |
| 7488    | _listing_price          | 12345        |
| 7488    | _listing_price_sortable | 12345        |
+---------+-------------------------+--------------+

4. git checkout 1.3.2
5. Edit the listing title and save the listing.

The _listing_price_sortable row will now be missing:

❯ wp post meta list 7488
+---------+----------------+--------------+
| post_id | meta_key       | meta_value   |
+---------+----------------+--------------+
| 7488    | _edit_last     | 1            |
| 7488    | _edit_lock     | 1562779081:1 |
| 7488    | _listing_price | 12345        |
+---------+----------------+--------------+

To fix

Fixed for me by changing these lines in agentpress-listings/includes/class-agentpress-listings.php:

-		if ( isset( $property_details['_listing_price'] ) && ! empty( $property_details['_listing_price'] ) ) {
+		if ( isset( $property_details[0]['_listing_price'] ) && ! empty( $property_details[0]['_listing_price'] ) ) {

-			$price_sortable = preg_replace( '/[^0-9\.]/', '', $property_details['_listing_price'] );
+			$price_sortable = preg_replace( '/[^0-9\.]/', '', $property_details[0]['_listing_price'] );

			update_post_meta( $post_id, '_listing_price_sortable', floatval( $price_sortable ) );
		} else {
			delete_post_meta( $post_id, '_listing_price_sortable' );
		}

New posts and posts that were edited would then have to be re-saved after this fix in order to restore the _listing_price_sortable.

Cause

The $property_details data structure changed here in 1.3.2:

And we missed that $property_details needed to become $property_details[0] at all points below that in the code, rather than just the for loop.

The link on the taxonomy ID is incorrect on the register taxonomy screen. If you click the ID, it should go to the edit screen similar to categories where clicking the category name or the edit link below it lead to the same page.

Currently, the links on taxonomy IDs lead to a page that says Please complete all required fields.
The incorrect link uses action instead of view.
wp-admin/admin.php?page=register-taxonomies&view=edit&id=test vs
wp-admin/admin.php?page=register-taxonomies&action=edit&id=test

This question is asked a lot on the StudioPress forums and other support channels. I have code for most of the sort options I share with them but it's dangerous for most users to do this in their functions file.

Sort by:

Price - asc or desc
Date - asc or desc
Random Order

Currently the taxonomies need to be registered with lowercase letters, dashes, and numbers only. Quite often, this instruction is either missed or ignored and customers enter capital letters or symbols.

This can break the listing search widget, scripts on the listing edit pages, and menus. Capital letters are fairly easy to fix by deleting and recreating, but certain symbols result in taxonomies that are broken and require using phpMyAdmin to edit the database to fix the issue.

The solution would be to sanitize the registration to avoid these issues.

When creating a new Listing post type, the Pricing field is stored in the postmeta table as a longtext value, which prohibits it from being sorted/treated like a number when queried.

Hello,
When you make a search, the properties shown, they've had the button: "View listing" and cannot be translated.

I've tried to search the string, but I don't see where is the problem.

Regards.

Request to have APL hide empty custom fields - https://wordpress.org/support/topic/hide-empty-property-listings-details

See https://wordpress.org/support/topic/shortcode-mod-to-hide-empty-fields?replies=4 for code.

In 1.3.0 and 1.3.1, iframe HTML entered into the Map Embed Code or Video Embed Code fields is cleared when saving the listing:

To reproduce

1. Edit or create any listing.
2. Add this HTML to the map embed code or video embed code fields:

<iframe width="600" height="500" id="gmap_canvas" src="https://maps.google.com/maps?q=university%20of%20san%20francisco&t=&z=13&ie=UTF8&iwloc=&output=embed" frameborder="0" scrolling="no" marginheight="0" marginwidth="0"></iframe>

3. Save the listing.

The map and video fields will be cleared after saving.

Plain text entered into those fields is not stripped — only HTML.

Cause

Seems to be due to the combination of:

1. Sanitizing text fields on save here:

2. wp_kses_post when displaying the meta boxes here:

We could perhaps change the array_map to only act on the text fields, and remove the wp_kses_post on output?

Further info

The issue is not present in 1.2.7.

• Introduced in b8cb921.
• Reported at https://wordpress.org/support/topic/property_map-embeds-not-saving/.

Sorry to miss this during testing, @marksabbath. (I tested those fields with plain text but not HTML.)

The addition of wp_kses here causes JetPack to change the iframe to a [googlemaps ...] shortcode with broken output on the front end. See this support issue.

It happens when the compose using shortcodes to embed media from popular sites feature is turned on.

The listing-city-state-zip span is output in the featured listings widget with a comma even when the city and state is not filled in.

The custom post type slug for listings is not translatable.

The fix for this is below.
class-listings.php line number 91:
'rewrite' => array( 'slug' => _x( 'listings', 'agentpress-listings' ) ),

Describe the bug
In 1.3.2 and 1.3.3, while on WP Core 5.3.1 content entered into the Property Details input boxes:

To Reproduce
Steps to reproduce the behavior:

1. Go to a site running WordPress Core version 5.3.1
2. Edit an existing listing or make a new listing.
3. Modify any existing value, or add new values.
4. Save the value

Expected behavior
The modified fields will be cleared after saving.

Video Replication
https://www.loom.com/share/ea0ce018108942268f06c3ccf11afbb1

Screenshot

Version

• WP Core 5.3.1
• agentpress-listings 1.3.2 and 1.3.3

Device and browser information

• OS: Mac
• Browser Chrome
• Version 79.0.3945.79
  Additional context

Reported at https://wordpress.org/support/topic/agentpress-listings-plugin-error-when-upgrading-wordpress-5-3-1/

As reported by a customer here, Listing taxonomy labels are not currently translatable.

The customer provided the following screenshots from WPML support, who suggest using the gettext filter to add translation support for drop-down labels:

From: https://github.com/copyblogger/themes/issues/843

If you create a listings taxonomy with an ID of ‘year‘ and then attempt to load any subpages, you will see the homepage at the subpage URL. WP will match the slug against 'year=' instead of 'pagename=', find no year, and serve the homepage:

We could auto-rename an ID of 'year' to 'years' or 'era' (both of which work).

'year' was the only slug I could reproduce this with — others such as post_id, postname, etc. do not cause an issue.

Taxonomy IDs cannot be renamed via the UI at present, so people encountering this either need to make database edits to rename the ID, or recreate their 'year' taxonomy as 'era' or similar, re-assign their listings to the correct 'era' instead of 'year', then delete the 'year' taxonomy and visit the Settings → Permalinks page to flush rewrite rules.

To reproduce:

1. Go to Listings > Register Taxonomies
2. Add a new taxonomy with ID ‘bathrooms’, plural name ‘Bathrooms’, and singular name ‘Bathroom’
3. Edit the taxonomy and change the plural name to ‘Bathroomz’

You’ll see that the edited taxonomy has a blank ID, and that the old unedited version is still present:

The following two error messages are generated when the taxonomy is edited:

[28-Dec-2014 23:29:52 UTC] PHP Notice: Undefined variable: id in /vagrant/wp/wp-content/plugins/agentpress-listings/includes/class-taxonomies.php on line 200

[28-Dec-2014 23:29:52 UTC] PHP Notice: Undefined variable: id in /vagrant/wp/wp-content/plugins/agentpress-listings/includes/class-taxonomies.php on line 204

Attempting to delete the taxonomy results in a ‘nice try, partner’ message.

Modifying the edit_taxonomy() method in class_taxonomies.php to define $id before using it on line 197 appears to fix the issue (fix included in PR#15):

        $id = $args['id'];

        $args = array(
            'labels'       => $labels,
            'hierarchical' => true,
            'rewrite'      => array( 'slug' => $id ),
            'editable'     => 1
        );

        $tax = array( $id => $args );

Additionally, maybe it would be worth changing the message that people see upon attempting to delete a taxonomy with no ID, so that it sounds less accusatory/confusing? (We had a complaint about this.)

Perhaps instead of, “Nice try, partner. But that taxonomy doesn't exist. Click back and try again.”, simply: “Sorry, but that taxonomy could not be deleted.”

Have you done the following in preparation for release?

• Bump version in all relevant and necessary locations.
• Create and execute db upgrade, if necessary.
• Build the styles/scripts if necessary (npm run build).
• Generate POT (grunt makepot).
• Verify CHANGELOG(s) has been updated.

Chris Cree shared code to hide empty fields in the [property_details] shortcode for single listing page. So, for example, if Basement isn't filled in, it isn't output in the shortcode.

    function property_details_shortcode( $atts ) {

        global $post;

        $output = '';

        $output .= '<div class="property-details">';

        $output .= '<div class="property-details-col1">';
            foreach ( (array) $this->property_details['col1'] as $label => $key ) {
                $value = get_post_meta($post->ID, $key, true);
                if ( !empty( $value ) ) {
                    $output .= sprintf( '<b>%s</b> %s<br />', esc_html( $label ), esc_html( get_post_meta($post->ID, $key, true) ) );
                }   
            }
        $output .= '</div><div class="property-details-col2">';
            foreach ( (array) $this->property_details['col2'] as $label => $key ) {
                $value = get_post_meta($post->ID, $key, true);
                if ( !empty( $value ) ) {
                    $output .= sprintf( '<b>%s</b> %s<br />', esc_html( $label ), esc_html( get_post_meta($post->ID, $key, true) ) );
                }   
            }
        $output .= '</div><div class="clear">';
            $output .= sprintf( '<p><b>%s</b><br /> %s</p></div>', __( 'Additional Features:', 'apl' ), get_the_term_list( $post->ID, 'features', '', ', ', '' ) );

        $output .= '</div>';

        return $output;

    }

Ref: http://wordpress.org/support/topic/shortcode-mod-to-hide-empty-fields

Initially tested to be working.

see http://ottopress.com/2013/language-packs-101-prepwork/

Customer request:

“Is there a way that the AgentPress Listing search widget can be searchable by Parent taxonomies, and if that parent is chosen then a sub-child taxonomy will be shown as additional multiple choice options?

Currently, all parent/child taxonomies are showing up and I would only like the child taxonomies to show if that particular parent is chosen.”

agnetpress instead of agentpress

A customer requests:

It would be great if there was a way to show the listings on a page or post (maybe there is but I can't figure out how as there seems to be zero documentation).

This could be done with a shortcode that shows a grid or single column list of the listings down the page. Thanks.

Have suggested using this plugin for now: https://wordpress.org/plugins/display-posts-shortcode/

[display-posts post_type="listing" id="123" include_excerpt image_size="medium" wrapper="div"]

Perhaps it would be worth having a shortcode that pulled in more metadata about a specific listing and presented it in a prettier way, though.

Pinging @nathanrice and @dreamwhisper on this:

http://www.studiopress.com/forums/topic/agentpress-search-listings-duplicated/