George Notaras

Hi Pat,

Here is some more info about the procedure.

As a first thing I’d make sure that all the domains you are going to test as part of the network installation point to 127.0.0.1, including the ‘www’ versions, eg:

127.0.0.1    example.com
127.0.0.1    www.example.com
127.0.0.1    demo.example.com
127.0.0.1    www.demo.example.com
127.0.0.1    example.net
127.0.0.1    www.example.net

Secondly, I’d add a virtual host in XAMPP’s apache making sure that all the domains that are going to be served by it exist in ServerName *or* ServerAlias directives.

Then, I’d transfer the files in the DocumentRoot of that virtual host exactly as they are arranged on the live server.

Finally, I’d locally create a database (using the same name as the one on the live server) in phpMyAdmin and import the data to it.

After restarting apache, the web sites should be accessible locally without making any requests to the live server.

Also, I just pointed a live domain to 127.0.0.1 through my desktop’s hosts file, set up a virtual host in XAMPP’s apache server and installed wordpress.

My browser can access the locally installed version of the web site (currently empty) instead of the one that is live on the internet. Accessing the admin interface works as expected as well.

So I’d assume that there is something done wrong on your end or the use case scenario is more complicated than it is described through these posts.

In any case I’d suggest to also ask in the Localhost forum.

I’m sorry for not being able to help you more with this.

George

Hi @patbell101

I thought your goal was to transfer the wordpress installation to another provider. What I suggested above was to edit your desktop’s hosts file and point your domains to the IP of the new provider after you had transfered the files and the database, so you could do a simple test if everything was fine without changing your DNS zone.

It turns out that your use case scenario is a little bit more complicated than what I had initially thought and I’m afraid that it’s a little difficult for me to understand the details of your environment through this thread.

So, I will kindly retire from it as I think I cannot provide much help about this issue as I have probably misunderstood the goal you are after.

BTW, if you are trying to test your web site locally, I’d highly recommend starting a new topic in the ‘Localhost’ forum.

Kind Regards,
George

Hi @webdevdlo

Nah, just another ordinary user review I guess. This has been a very reliable plugin so far for my use case. I have only good things to say about it. ??

Hi @sk15

Yes, preventing the plugin from generating metadata on a particular page is possible via filtering.

I just added a metadata exclusion example on the wiki. Your question was a good reminder for it.

If you have any more questions, please feel free to post them.

Kind Regards,
George

Hi, thanks for the kind review! Very glad you like the plugin!

Suggestions and feedback are always very welcome. If I understand correctly, you’d like the plugin to filter the head section and remove any duplicate meta tags. There was a time in the past I had considered doing this, but the idea was soon abandoned, because it was unclear if it would be possible for the plugin to do it right avoiding any ‘race conditions’ with other plugins. Moreover, I’d like to avoid any interference with the functionality of any other plugin. So, for now, the check about the existence and removal of duplicate meta tags is left to the user.

But, this is a good reminder to re-check if there is an efficient way to do this. As soon as the development of some features that have high priority right now is over, I’ll definitely look into this more closely.

Again, thanks for your review and feedback.

George

B-rad, thanks for your review and for all ideas and feedback! It is much appreciated!

Hi @b-rad

The idea was to keep Dublin Core metadata to content pages only (posts, pages, attachments and custom post types except products), so it is not generated for archives at all. Currently, it is not in the plans to add support for archives, but, if this is needed, I’ll see if it is possible to add some basic Dublin Core meta tags for archives.

About the front page, most probably you are right. Since a static page is used, it would make sense to generate DC meta tags for it. From what I see the current check does not take this into account. This possibly will have to be fixed.

During these weeks my free time is very limited. I’ll try to look into this as soon as possible and reply back with some more info.

Thanks for your feedback!

George

Hi,

I think I should have clarified it a little better. I meant the hosts file on your desktop, so that the web browser resolves your domain to the new IP so that you can check the web site on the new provider.

George

Hey, relax. It’s probably the IIS web server running on port 80 (MS had this “brilliant” idea for Win10). Open a terminal with administrator privileges and run:

net stop w3svc

Then restart apache and try to visit your locally hosted web site.

Hope this helps.

George

Hey all,

I tested it with the current stable WordPress version (4.4.2). Mapping arbitrary domains can be done without a domain mapping plugin, but I could not make it work correctly (issues logging in to sub-sites) without also adding Ipstenu’s wp-config.php option that sets the COOKIE_DOMAIN dynamically.

How to:

1. Create a network installation using sub-domains.
2. _Add_ a new site using any sub-domain, eg abcd.wp.local. The sub-domain does not have to exist in the DNS zone.
3. _Edit_ the newly added site and, under the Info tab, set the URL of the site using any arbitrary domain. Use the correct protocol and trailing slash, for instance: https://wp1.local/
4. That’s it. Everything else is taken care of automatically and accessing the public sites as a non authenticated user should work just fine.

But, logging into the sub-sites does not seem to work. At least it doesn’t work in my test network.

I had to also *add* the following in wp-config as noted in the linked post above before I could log in to the sub-sites:

define( 'COOKIE_DOMAIN', $_SERVER[ 'HTTP_HOST' ] );

Then logging in worked fine.

Then I thought of setting the DOMAIN_CURRENT_SITE option dynamically using $_SERVER[ 'HTTP_HOST' ] and remove COOKIE_DOMAIN. wp-config looked like this:

define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
//define('DOMAIN_CURRENT_SITE', 'wp.local');
define( 'DOMAIN_CURRENT_SITE', $_SERVER[ 'HTTP_HOST' ] );
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

This also seems to work, but the fact that SITE_ID_CURRENT_SITE and BLOG_ID_CURRENT_SITE have a static value (=1), while the value of DOMAIN_CURRENT_SITE is set dynamically, doesn’t make much sense to me.

So, my final thoughts are that, if you map domains without a domain mapping plugin, you also have to at least use the workaround from Ipstenu’s article. At least means that there might also be other things that have to be tested.

The fact that the official documentation does not mention this way of doing things tells me a lot.

Since this is for a customer and, especially if this is about e-shops or literally anything else that has to do with sensitive personal information, you should not take my word for anything of the above, but test it extensively yourself to make sure that everything works as expected.

I’d say that going ahead with an undocumented solution, especially if this is about a serious project, is not a wise decision. Instead, I’d use one of the two well known and widely tested domain mapping plugins mentioned by Tony above.

Hope this helps. Any more information about mapping domains in 4.4 without a plugin would be much appreciated.

George

That’s great!

Hi Takayuki,

Very glad you found the feedback useful. I also found some great documentation of yours at:

* https://contactform7.com/configuration-errors/
* https://contactform7.com/best-practice-to-set-up-mail/

I finally think I should have done some more research. My questions would have mostly been answered.

However, adding a small section in the FAQ about the aforementioned concerns and linking to it from the warning message regarding the non-validated contact forms would still be nice.

BTW, I played with this feature a bit and I think it’s great and every validation makes perfect sense!

My only suggestion would be to add a filter based switch like the following:

add_filter( 'wpcf7_validate__relaxed_from_email', '__return_true' );

which would make the rule, which checks if the email address that has been added to the From field belongs to the exact domain of the web site, a little more relaxed by allowing email addresses the domain part of which is a parent domain of that of the web site’s.

I’m sure I could have phrased the above better, so here is an example to make it more clear: provided that the above filter is set to True, if the web site’s domain is blog.example.com or test1.demo.example.com, the validator could allow an email address of the form [email protected] in the From field, but not an email address of the form [email protected].

For instance, in case of a multi-site installation, in which each sub-site is operated by different people, the current strict validation rule makes *perfect* sense, because in such a case all sub-domains should have separate MX records in the DNS zone, which usually translates to different mailboxes.

But, in case all the sub-sites are operated by a single person (happens some times), chances are that there are not separate MX records for each sub-domain, but the same email address and mailbox are used for all sub-sites, which is the expected thing in almost all such cases.

On the contrary, with the current strict validation rule in that latter case the multi-site operator, in order to be able to use the same mailbox for all sub-sites, would have to add an MX record and also an email alias ([email protected] address pointing to [email protected]) for *each* sub-domain. Most of the time people won’t like having so many valid email addresses around as it could lead to receiving more spam.

By supporting a switch like the one above, the validation rule could become a little relaxed with this so as to cover these cases.

I hope I am not missing anything in all the above. ??

In any case I think the implementation of the validation is excellent and I hereby take back my suggestion to make it an on-demand feature. ??

Best Regards,
George

IMHO, creating a small FAQ about the validation process of existing forms and pointing to that from the warning message would greatly help people make a decision.

Some questions I had as soon as I saw the warning:

* My form is working fine. What is going to happen if the validation fails for whatever reason? Will the form continue to work?
* Will I be able to save a form if validation fails?
* What does the validation actually check?
* Does it validate the settings by sending a test message? Does it use any external service?

I think that’s all. ??

Best Regards,
George

Hi Takayuki,

Thanks for your quick reply.

It is just a useful tool that tells you when you have mistakes in your configuration. You can just ignore it if you think you don’t need it.

For most users, this function is necessary to be always active because they often make mistakes. I think there is no reason to hate the harmless guide.

Its usefulness is unquestioned. The form validation is a much needed feature and I’m sure it is going to help many users configure their contact forms correctly.

I think there has been a misunderstanding here. In fact, I think the feature is great! ??

I was just suggesting that the persistent warning message about the pending validation of the existing contact forms could be replaced by an on-demand validation link (one like those links that appear when you hover over an existing form in the forms listing page). The automatic validation on newly created forms is not a problem. But I’m sure that most people would be hesitant to validate working forms, unless there was some more info about the validation process and what would happen if for any reason the validation of a working form failed. For example, would that form continue to work? Form validation is a new feature, it might have bugs or the validation rules may not cover the wide range of email server configurations or special contact form requirements.

So, what I’m actually questioning is the necessity of the persistent warning message which admittedly forces users to commit an action on forms that are confirmed to work.

I hope I’ve clarified what my feedback was about. The feature is great and I think everyone is grateful for it! ??

If you still want to deactivate it, see https://www.ads-software.com/support/topic/configuration-errors-found-after-updating

Oh, I see. It seems I should have done some more research about it. ??

It doesn’t use any external services for the configuration validation.

The reason I asked is that in many web applications email configurations are usually tested by sending a test email message. I had read a post containing release notes but it did not clarify the nature of the validation. Now that you’ve clarified it I think I’ll go ahead and validate the form.

Thank you for the insight! It is much appreciated.

Again, thanks for a great plugin! ??

Kind Regards,
George