George Notaras

Hi Beno?t,

If it is not possible to remove the plugin from the WP plugin management interface, then it definitely looks like a problem with the filesystem permissions.

May I ask how you installed the plugin? Did you use WP’s ‘Add new plugin’ feature (at /wp-admin/plugin-install.php) or did you upload the plugin via FTP or via any other web interface at the hosting provider’s control panel?

If the latter is the case, please remove the plugin by manually deleting the directory /wp-content/plugins/creative-commons-configurator-1/ using FTP or the hosting provider’s control panel.

After this is done, try to install the plugin by visiting /wp-admin/plugin-install.php on your blog (Plugins -> Add New).

I would highly recommend installing plugins via the WP plugin management interface.

Please let me know if it worked.

George

Hi b-rad,

The issue with the static front page has been fixed for the new release.

However, the addition of DC metadata to the archives will be delayed for a while, because some more research is required for this. I plan to implement it together with Schema.org metadata for archives.

I will now mark this topic as resolved. Please feel free to open a new one for any suggestion or issue report.

Kind Regards,
George

Hello Marie,

I’m going to close this topic. If you have more questions, please feel free to open a new one.

Kind Regards,
George

@bmelancon

Hi Beno?t,

Thank you for your feedback.

I’m looking into this issue right now, but I cannot explain what might be causing the problem.

Is this the first time you install it or was this an upgrade from a previous release? From a technical point of view, nothing has changed in the core of the plugin since the previous releases so installing/activating/deactivating/deleting should work as expected..

Have you ever encountered the same issue in the past with another plugin?

The fact that you encounter this problem on the /wp-admin/plugins.php page tells me that possibly the issue is not related to the plugin. The plugin doesn’t even use any activation/deactivation hooks, so activating/deactivating is entirely done by WordPress.

Could you please try the following?

1) Completely remove the plugin by deleting it from the WP plugin management screen at /wp-admin/plugins.php
2) Log out of your blog.
3) Clean the web browser cache. (this is the important step)
4) Log in again.
5) Install the plugin from /wp-admin/plugin-install.php
6) Activate the plugin at /wp-admin/plugins.php

Please let me know if the problem persists.

Kind Regards,
George

Hi Agnes,

Thank you for the kind review! It is much appreciated!

Always glad to implement nice ideas about useful features.

I’ll be working on the plugin again shortly and provide some more info through Github.

Best Regards,
George

Please note that the solutions posted above *will* work with domain aliasing. In fact, now that I think about it, domain aliasing is possibly going to be required, so that all domains are served by your multi-site installation (don’t really know how your environment is configured). The domain mapping plugin or the custom rewrite rule I posted above will direct each request to the relevant sub-site or parked.html.

If you need more clarification, please feel free to ask.

George

Hi @patbell101

I just noticed this message. I’ll reply here as a follow up to the previous discussion about the domain migration.

I have started a new thread but wonder what your take, george, is on parked domains, alising or redirecting?

About domain aliasing and redirection, if this was not your initial intention, I wouldn’t recommend going ahead with any of these.

First of all, domain aliasing means that the same content is going to be available from multiple domains, which is generally considered bad practice because search engines don’t like that. The only case in which domain aliasing is useful is for the www version of a domain and even then an additional 301 redirect to either the www or the non-www version is highly recommended.

Secondly, domain redirection between different domains is only really useful when migrating your web site to a different domain, in which case you place a 301 redirect from the old domain to the new one.

To me neither domain aliasing or redirection make sense in this case, so I wouldn’t recommend them.

On the other hand, the concept of parked domains is just like regular domain hosting, but the web page that is served to visitors is just an informational page or a page with ads or a maintenance / under construction / coming soon page etc. In other words, they are just regular web sites, but not content oriented.

Since you have a multi-site, you could create a sub-site for each of the domains you would like parked, map each domain to the respective sub-site using a domain mapping plugin, and then point the domains’ A records to the multi-site’s IP address in the DNS zone. Once this is done you could use something like a static WordPress page with an informational message, or use maintenance / coming soon / plugins/themes on each sub-site.

If setting up separate web sites is too much work, you can always inject a mod-rewrite rule in the htaccess file and redirect requests to those web sites to a predefined static html file you have created. for example:

1. Make sure the A records of the domains (to be parked) point to the multi-site’s IP address.

2. Add the following in the beginning of the htaccess file.

RewriteCond %{HTTP_HOST} ^(?:www\.)?(?:example\.com|other\.example\.net|more\.example\.org)$
RewriteRule . parked.html [L]

3. Edit the example domains with your own domains in the above rule, keeping them separated using the | character.

4. Create a file named parked.html and place it in the root directory of the wordpress installation. The file can contain any HTML template you would like to be displayed when the parked domains are visited.

That’s it.

Well, the reply ended up being quite long. I hope this is all clear.

George

Hello @yamaryam

Thanks for your question and I’m sorry for the late reply.

Microformats is different type of metadata than Schema.org Microdata. Due to the nature of microformats, they can only be added in the theme templates by theme developers. It is impossible for Add-Meta-Tags to change or add the microformats classes.

You can find more information about Microformats here.

Kind Regards,
George

Hi, you are welcome! Glad to hear it has been sorted out.

For testing it locally all you need to do is direct your web browser to a local installation. This can be done by pointing the domain to 127.0.0.1 in the hosts file. The WP installation is IP address agnostic, so you can test it literally anywhere.

George

Hi @penseelibre

Thank you for your review!

I always try to make the configuration as simple as possible, but I admit that there is much room for improvement in this particular area. I’m sorry for any inconvenience, but, unfortunately, my free time is not enough at the moment to redesign the interface in a more user friendly way.

While on the plugin settings page at Settings -> Metadata, you can find some more information about the options by pressing the Help button on the top right corner. Apart from that, please always feel free to post your questions in the forums or on Github. Usually my responses are fast, but sometimes it might take a while.

Seeing the changes in the Structured Data section of Google Webmaster Tools might take a while (days/weeks). It really depends on other factors and not on the plugin.

Finally, I’d like to point out that content is king and the efficient promotion of it should always exist in the agenda.

Again, thank you for using the plugin and for your review! Much appreciated.

Kind Regards,
George

Also, I should note that I’ve done all these tests with Mozilla Firefox on Windows.

Any changes made to the operating system’s hosts file took effect immediately without even having to clear history or flush the DNS cache.

This is just a note just in case any other browser performs DNS resolution in a way that bypasses the operating system. However, I’m not aware of any such thing, but then again I haven’t done any research about it.

Hello,

George, I’ve got a bit confused with the localhost stuff here. So to clarify the current situation.I have copied all my public_html files to my new host, and restored the database, apparently successfully.

Then the job is almost done. The only thing left to do is change the relevant records in the DNS zone so as to point to the new IP.

In order to test without changing the DNS zone, you could trick the browser by adding the relevant entries in your desktop’s hosts file as described above, but from what I read you have also done that.

I have disabled .htaccess and at the newly copied database has the same name and user as the old one.

htaccess is necessary. The only thing needed is to make sure that any security plugins do not interfere with you local test installation. Otherwise, please leave the htaccess file in tact.

I am trying to test my new hosting prior to changing my dns. I have changed my Hosts entry and now when I ping … it returns NNN.NNNN.NNN.NNN which fwiw is the IP address of my new host’s server.

This means that you have set up the local hosts file correctly for the test.

All that is left is test the web site with your browser from the box on which you have modified the hosts file.

The codex just says “to test before you switch, you must temporarily change “siteurl” and “home” in the database table “wp_options”” but to what do I change them? With no changes accessing my root domain and subdomain sites just goes to my old host.

There is actually nothing that needs changing in the database since you are just switching hosting providers (just different IP). If your goal was to also change the domain name of your web site, then making the changes to the database would be necessary, but this is not the case.

I assume that the codex page refers to the case of changing the domain name of your web site. BTW, there are many ways to do things. The codex sometimes tries to cover all of them for the convenience of users, so I’d suggest posting the exact page you are referring to would be very useful in order to understand what it is about.

Apart from all the above, I outlined the required procedure above. If any other steps were required, I would have posted them.

For anything else about a localhost installation, please post a new question in the ‘Localhost’ forum.

Hope these help.

Kind Regards,
George

Also, I think I’ve figured out a possible cause why you might be getting a Not Found error when accessing the admin interface. This issue must have to do with SSL.

If you are accessing your normal live web site over SSL or have configured it to access the admin area over SSL, you should either make sure your local virtual host is configured for access over HTTPS or edit the URLs in the database or finally remove any configuration options like the following from wp-config.php:

//define('FORCE_SSL_LOGIN', true);
//define('FORCE_SSL_ADMIN', true);

Update for correction regarding a previous post:

Also, any security related rules in htaccess should be double checked so that they interfere.

Meant to be ‘so that they don’t interfere.’

Forgot to mention that wp-config.php should be edited and you should make sure the database name is correct, the DB_USER is set to root (unless you have set up users differently in your local MySQL server) and DB_PASSWORD is empty ('').

Also, any security related rules in htaccess should be double checked so that they interfere.

George

Now that it is clear what your goal is, please feel free to ask any questions (if any). ??