Michael v.d. Berg

Just go to the support page of WordPress.com, because that is another environment then this self-hosted WordPress(.org) website. You can contact them via this link and choose for the option wordpress.com account recovery.

You can do this without an plug-in. If you upload the PDF file, you can add the parameter #page=number to the URL, where you replace ‘number’ with the required page number. So for instance https://www.unescap.org/sites/default/files/Introduction%20to%20ICANN.pdf#page=10 to reference to the PDF page 10. Remember that this number is the page number of the entire PDF and not the page number at the specific page.

After that you can create for instance a bullet point list to redirect and add the link text to it. Or you can follow this guide to add a dropdown list via the ‘code’ tab in your page or blog post. Just make sure that the words are text with the link tag. With some CSS you can style the dropdown list as well.

Of course you can use a plug-in, but I would suggest to use this way, because an extra plug-in for this feature will cost some extra loading speed of your WordPress website.

Did you try to re-install the WordPress core files via de Dashboard –> Updates function? If this does not help, then I would advice you to enable the WP-Debug option in your wp-config.php file (located in the main folder of your WordPress installation). With this option you can probably notice where the error is coming from. If you have access to your webserver (DirectAdmin, Plesk, cPanel), then you can look at your server error logs to see if you can find something there.

I had a similar error a few weeks ago. My update page was frozen when I click on update plug-ins or translations. I solved this by re-uploaden the core files from the WordPress website, and upload these files with a FTP-client (such as FileZilla). Maybe this will help you as well with solving this issue.

Did you checked if the WordPress Max Upload Size, WordPress Max Uploads Files, Memory Limit and PHP version is suffici?nt? Otherwise you can try to make the values a bit larger (if available) to see if you can install it successfully. You can find these settings in your webserver (DirectAdmin, Plesk, cPanel), or you can add/change them in your wp-config.php file.

The easiest way is to access the website with FTP (File Transport Protocol). I do not know if you have access to the FTP credentials? But with software, such as FileZilla, you can access the website and change the wp-config.php file with the debug mode. Or you can (temporary) deactive the plug-in in the /wp-content/plugins/ in the webserver to change the plug-in folder name (for instance from plugin-1 to plugin-1-deactive).

A second way is to look at the back-up on your harddrive (assuming this is a full website back-up). If you go to the wp-config.php file, you can find the credentials of the database (MySQL) (database name, database password). If you know the database url to access phpMyAdmin for instance, then you could create a new admin user. Hopefully you can use this way to work around the issue and deactive the plug-in in the dashboard. For instance by changing a table name in the database. Please note that you should take a full back-up of the website/database before you do this step.

If this is not possible, than the only solution is the find the cPanel credentials or contacting the webhosting company with an email or domainname verification.

Did you tried already to enable the WP_Debug already in your wp-config.php file in the root of your webserver (where WordPress is installed)? If you did, are you using also a caching plug-in? In that case you could delete the cache files and rename the caching plug-in temporary by going to the plugins folder in wp-content. Mostly there should shown some WordPress error logs.

Otherwise it should be server related. I know on another WordPress website with a premium theme that there is an issue with the PHP 8.1, but with PHP 8.0.x are no errors. Did you tried that as well?

If you have access to your webserver folder public_html or private_html (depending on your set-up), you can create or use the .htaccess file. Sometimes it works to set the PHP version back to an older version. You can try this with the following code below. You can change the 71 to the version you prefer on the second row. For instance php74 will use the php 7.4 and 71 the php 7.1

<FilesMatch "\.(php4|php5|php3|php2|php|phtml)$">
SetHandler application/x-lsphp71
</FilesMatch>

If this doesn’t work you can read the article of Kinsta about this error. But to be sure. Your WordPress, themes and plug-ins are up-to-date?

Yes, it should be possible to archive the new label for two months on your WooCommerce webshop. You can follow the next tutorial and see if this works for you: https://www.businessbloomer.com/woocommerce-new-badge-recent-products/

Please be aware that you paste the code in your child-theme functions.php, otherwise your changes will be removed when your main theme will be updated. Also make sure you back-up your website and/or webshop before you made changes like this.

Could you try if one of this solutions will work?

– What happens when the person will enter the website with the manual https:// in the URL?
– Is there an two-steps verification active? (If so, could you deactivate it)?
– If you open the inspector tool (in Chrome: CTRL + Shift + i) and go to the console tab, are there any errors shown?
– What happens when you deactivate temporary all the plugins and see if the person can login again?

Hi Edo,

Thank you for your patience! I tried the plug-in on a fresh installation of WordPress without any other plug-in or theme. It runs only with the Twenty-Twenty-one theme on a different webserver. The plug-in works fine with PHP 7.4.20, but when I move the PHP to 8.0.7 the plug-in doesn’t work anymore. It shows only the title of the widget with the “glt_widget-2” ID. The id “google_language_translator” is showing in the source code/inspector tool, but it is completely empty. The code that shows on PHP 7.4.20 (see here below) isn’t there in the source code/inspector tool on PHP 8.

I checked the inspector console and the PHP error log (also in WordPress debug mode) but there isn’t any error showing up.

<div class="skiptranslate goog-te-gadget" dir="ltr" style=""><div id=":0.targetLanguage"><select class="goog-te-combo" aria-label="Widget Language Translate"><option value="">Selecteer een taal</option><option value="af">Afrikaans</option><option value="sq">Albanees</option><option value="am">Amharisch</option><option value="ar">Arabisch</option><option value="hy">Armeens</option><option value="az">Azerbeidzjaans</option><option value="eu">Baskisch</option><option value="bn">Bengaals</option><option value="my">Birmaans</option><option value="bs">Bosnisch</option><option value="bg">Bulgaars</option><option value="ca">Catalaans</option><option value="ceb">Cebuano</option><option value="ny">Chichewa</option><option value="zh-TW">Chinees (traditioneel)</option><option value="zh-CN">Chinees (vereenvoudigd)</option><option value="co">Corsicaans</option><option value="da">Deens</option><option value="de">Duits</option><option value="en">Engels</option><option value="eo">Esperanto</option><option value="et">Ests</option><option value="fi">Fins</option><option value="fr">Frans</option><option value="fy">Fries</option><option value="gl">Galicisch</option><option value="ka">Georgisch</option><option value="el">Grieks</option><option value="gu">Gujarati</option><option value="ht">Ha?tiaans Creools</option><option value="ha">Hausa</option><option value="haw">Hawa?aans</option><option value="iw">Hebreeuws</option><option value="hi">Hindi</option><option value="hmn">Hmong</option><option value="hu">Hongaars</option><option value="ga">Iers</option><option value="ig">Igbo</option><option value="is">IJslands</option><option value="id">Indonesisch</option><option value="it">Italiaans</option><option value="ja">Japans</option><option value="jw">Javaans</option><option value="yi">Jiddisch</option><option value="kn">Kannada</option><option value="kk">Kazachs</option><option value="km">Khmer</option><option value="ky">Kirgizisch</option><option value="ku">Koerdisch</option><option value="ko">Koreaans</option><option value="hr">Kroatisch</option><option value="lo">Lao</option><option value="la">Latijn</option><option value="lv">Lets</option><option value="lt">Litouws</option><option value="lb">Luxemburgs</option><option value="mk">Macedonisch</option><option value="mg">Malagasi</option><option value="ml">Malayalam</option><option value="ms">Maleis</option><option value="mt">Maltees</option><option value="mi">Maori</option><option value="mr">Marathi</option><option value="mn">Mongools</option><option value="ne">Nepalees</option><option value="no">Noors</option><option value="uk">Oekra?ens</option><option value="uz">Oezbeeks</option><option value="ps">Pashto</option><option value="fa">Perzisch</option><option value="pl">Pools</option><option value="pt">Portugees</option><option value="pa">Punjabi</option><option value="ro">Roemeens</option><option value="ru">Russisch</option><option value="sm">Samoaans</option><option value="gd">Schots Keltisch</option><option value="sr">Servisch</option><option value="st">Sesotho</option><option value="sn">Shona</option><option value="sd">Sindhi</option><option value="si">Sinhala</option><option value="sk">Slovaaks</option><option value="sl">Sloveens</option><option value="su">Soendanees</option><option value="so">Somalisch</option><option value="es">Spaans</option><option value="sw">Swahili</option><option value="tg">Tadzjieks</option><option value="tl">Tagalog</option><option value="ta">Tamil</option><option value="te">Telugu</option><option value="th">Thai</option><option value="cs">Tsjechisch</option><option value="tr">Turks</option><option value="ur">Urdu</option><option value="vi">Vietnamees</option><option value="cy">Wels</option><option value="be">Wit-Russisch</option><option value="xh">Xhosa</option><option value="yo">Yoruba</option><option value="zu">Zoeloe</option><option value="sv">Zweeds</option></select></div></div>

Thank you for your reply! When I enable the wp_debug function I get only two errors in the PHP error log, which are the same but with a different timestamp. The error is:

PHP Notice: ob_end_flush(): Failed to send buffer of zlib output compression (1) in /wp-includes/functions.php on line 5107

I disabled the Zlib output compression in the PHP settings and the errors are not showing anymore. There are no errors or issues mention on the pages where the plug-in widget is active on, such as error on line x in file x.

After that I enabled also the JS and CSS debug function and the wp_debug_display, but I didn’t get an error or issue on the pages or in the PHP error log. Also the wp_debug_log didn’t show any errors or issues.

I will install tomorrow a fresh installation of WordPress on a dev subdomain to see if there are possible conflicts with other plug-ins or with the WordPress theme itself on PHP 8.

For so far, thank you! Keep you posted!

That’s weird. For me it works well when I visit the URL and order something in the basket. Can you check to update the browser which you mostly use and see if it is the same browser version on both computers?

Are you using a caching plug-in? If so, could you try to delete the cache withing this plug-in. There is most of the times a specific button for.

Otherwise you can go to settings, permalink and click (without changing something) at the save button. This will resolve also problems.

Are you using maybe a blog category and a page with the same url? Mostly the content “Sorry no content matched your criteria” has been used by a search form or by a blog category.

Could you try to go to settings –> Permalinks –> Save settings (without changing something).

It’s dependent what your webhosting allowed to the customers. Mostly you can change the memory limits in DirectAdmin, C-Panel or Plesk. For example when you change the PHP version from default to PHP 7.1 or something like that (be sure you made a back-up and your website (theme + plugins) is compatible with PHP 7.1)

• This reply was modified 6 years, 5 months ago by Michael v.d. Berg.

The problem in this case is the https://. When you remove the S from https:// –> https://, I will see the theme “Twenty Seventeen”. When I go to https://clarksvillehomerepairs.com/wp-admin I could login when you have the username and password.

If you still got the same 404-error, please be sure your delete all your browser cache from your browser (or visit the website in an incognito tab).

Don’t worry and you are welcome! If you need any help, please add here a new reply.

You can try if you could add the redirect at the end of the .htaccess file and check if your redirect works and that you are available to access your WordPress installation in the test folder. Otherwise you should clean the root .htaccess file and add only the redirect 301 or 302 code in it.

So before you start, make sure you copied (or save it somewhere) the .htaccess files to your local harddrive, for a back-up if something goes wrong.

If you have everything what you want from the root installation, you are safe to delete that installation. When you delete this installation, you have to create a new (clean) .htaccess file in the root folder. In the root .htaccess file you put the redirect 301 (or 302) code in it. (301 = permanent redirect / 302 = temporary redirect).

If you have change the URL’s, it’s should work correctly by domain.com/test/wp-admin/.

Did you know that you could install a dev installation in a subfolder? (Mostly every webhosting support subdomains). You can create something like dev.domain.com. So you can create a “Under construction” page in the root of the domainname. For example with a fresh WP installation and Under Construction plugin. So you are able to move your dev installation to the root folder when you are finished with the development.

I would like to recommend you to have a back-up first before you changed something!

If you have any questions or if you need help, please let me know!