ditikos

Probably you should see what the CRM needs in terms of data (title? agent? photo url? etc), how it needs to be inserted to the CRM and then you would need to make a page that draws these data (probably in xml format containing those data, taken realtime or cached for an amount of time) from the wordpress database.

It is fairly easy if you check the codex. You would probably need to have knowledge or assistance from wordpress codex https://codex.www.ads-software.com/ and how to use wpquery (at most).

You should go to settings > general. Probably there you have “New user default role” set up as an administrator. Otherwise, you have a plugin that overrides that functionality.

Try to add a static page for example test.html with a simple html paragraph, and load it from the url you mention, like https://www.webrockrevolution.com/test.html

If it works like that then you might want to check your database for proper encoding (utf8 or utf8mb4 if your db supports) and check if it corresponds to your wp-config.php database encoding.

Check back if you did the steps above.

Thank you Emily. I’ve been testing that plugin for a while now.

It seems that there are more than hooks to attend to (in contrast with the plugin I wrote for support). Also every problem has been resolved with the above plugin Emily mentions. You only need to make the same pages available in every store language.

So far I was able to get that functionality back on the checkout by remarking the

add_filter('woocommerce_get_checkout_url', 'pll_woocommerce_get_page_id');

on the plugin. But I don’t get the cart url on the mini-cart as well, which could be due to my theme but fyi.

You have the user registreation enabled in your wordpress install, so everyone subscribes there. Check users to see if they truly exist or is a spamming/phising service.

In firefox everything is ok, so do (surprisingly) in IE9+
I switched back to 3.7.1, all is fine (it annoys me though).

Nevermind, it was on the FAQ (the redraw case), thank you ??

Thank you for replying. I tried domain parking but didn’t work.

My host though, created a subdomain that points to the www document root of the main server so it is fixed.

One other small request. Can we use local tlds instead of official ones? For example during my development I have a hostname.local instead of hostname.com domain, but the plugin says it needs a hostname.com to operate it properly (so I had to alter my hosts file).

In the wordpress options table (mine is called wpp_options), wp-property adds an entry called wpp_settings that has the configuration of wp-property (initial values and values that you setup via the settings page when you install the plugin).

One of this properties refers to the language the google geocoding api translates to (variable: google_maps_localization). In order to setup this property (default is en locale, which means every address you type in every language it reverse locates it and returns the data in english language), there is a dropdown box on the properties page. This means that when I choose an address to type into wp-property entry, either it’s german either it’s chinese, or in my case, greek, it will generate the reverse address (or the nearest address data) in ENGLISH. If I recheck that in greek (EL) it will translate the above addresses in greek. But the problem is that this setting is global for the wp-property.

The same thing stands for choosing your own page to override property settings. I would like for example to have a different page for english properties (whereas english I mean international), and a different page for greek properties (remark: not properties in greece, but the language of the page).

So my thoughts are that when it is detected that wpml exists (I might try to implement it myself but it seems too big work for a simple customization) it needs to do this:

1. basic fallback page (en) with all the wp-property settings set there initially.
2. for each different wpml language setup a second ruleset that is dependent on that language. for example, I have enabled greek (el, my native language) and spanish (es), which means that:
every option I do while I am in greek, will stay for the greek site only. and in spanish for the spanish site only, just like how the wpml plugin works, on posts, pages, custom types etc.

I am already trying wpml, thank you. But there are these problems:

0. Localized address from google. It happens with the google maps geocoding api I have done it full custom on non wordpress, non property sites. I just want a different configuration when I have greek on (el.www.ads-software.com/rentals style or https://www.www.ads-software.com/en/rentals) to find my addresses in greek, and english when using the english configuration. If I type greek and having the setting for reverse address in english, it will bring me english. The reason I want this is to create a search similar to airbnb — typing a location as a required search step. (that means ditching property_search for now and maaybe property_overview, unless there is a way to preload these data for property_overview, by using a wp_query object). I am thinking on replicating the settings into a different entry followed by the icl_locale thing that wpml generates.

1. I won’t be using the [property_search] tag, since I need a special filter (see above)

2. I have already seen the wp_property settings in wp_options so I can repopulate the other search fields (which I can control from the configuration menu), for a specific functionality (post filtering my data).

So my actual problem at the moment is not making it multilingual (which it works, I’ve tested with the /{lang}/ option and it’s very great btw!), but making the settings work in the multilingual environment. FYI the selector does appear on the property settings page, so it can work with a hack.

Does this work for nginx too?

It’s a nice product indeed mr.Kostin.

My problem with the sorter was mainly that even when using the dropdown setting, I couldn’t get ascending / descending order. The second button for asc/desc was deactivated, I searched the code and found out in templates/template-functions.php that the code for wpp_sortable_dropdown (a grey icon displaying the asc/desc of the dropdown) was not operational. It did show the dropdown options (i.g. every field I put in for sorting) but not a way to do ascending/descending sort of that field. I did unmarked the code and it was fixed (unfortunately now, I can’t use any upgrades of the wp-property if they come out in this state because of this tweaking).

Anyway, as for the pagination, I am guessing I am going to have to do a manual post query (using the standard wp_query() method) for pagination and perhaps getting my data, but still using the very good backend interface (mostly that was what intrigued me on using wordpress+properties in the first place, I would have used any cms with custom field work instead).

Hmm, actually I don’t see any settings for such at the settings page of the developer.

Ok, mostly what I mean is the sorter you use on the [property_overview]. I’ve been able to dig up some code on the template functions php codes, to have it operational.

Now I need something to change the pager into the normal 1..2..3 instead of the slider. Is there something to tinker with?

I have generally been experimenting a lot with the templates portion of the wp-property. I’ve made some complex javascript slider designs mostly with the gallery links provided by wp-property (differenting from wpp gallery). Added a bookings theme plugin I created (co-dependent on wp-properties), so now I need to do a very customized search on wp-property which the [property_search] or something similar will refine the data than fetching them.