paulswarthout

Most likely the problem has to do with some same-named styles and the order in which they are loaded. I don’t own a copy of Updraft Professional to test with. Are you using Updraft Pro on a site you’re building? Or on a site that is complete and in production? If the latter, you should uninstall or at least deactivate the Child Themes Helper. It doesn’t need to remain installed for your Child Theme to continue to work.

• This reply was modified 1 year, 4 months ago by paulswarthout. Reason: To set the notify of follow up replies option

That is not a problem with the Child Themes Helper (CTH) plugin. CTH does not participate in the loading of the webpage or WordPress dashboard and can be uninstalled after creating and configuring the child theme, if you no longer need to move or copy files.

I would guess, that’s a problem with either the WordPress core (how it recognizes the child theme), or the parent theme code (where it looks for its code).

Look for hard coded paths to files in the parent theme and change them to match the Child Theme’s path.

Thank you. But, like I said, the removal did not work when I got that error message.

“In Queue” was just something I noticed when it didn’t work. I don’t know whether it is connected to the issue or not. I too am a developer. I know how hard it is to track down errors with vague information. I was just trying to be as specific as possible. ??

Hi @ryankienstra ,

I have used the DevTools preference ‘Disable cache’. That does work much of the time. Unfortunately, sometimes Chrome seems to ignore that setting. I’ll be debugging code and the page will start acting weird. If I clear the files/cache, everything will start working correctly again.

By clear the image/file cache, I meant — chrome://settings/clearBrowserData. Set the time range to All Time, and on the Basic tab, check the box Cached images and files. Then tap the Clear button.

For now, I thought I’d write a simple plugin to modify that line of code should it ever change. Shouldn’t be too hard. ??

You have a great weekend as well.

Do you mean: when you open a URL?
Like this: https://www.mydomain.com:8080

How big is the .mp3 file? Is it bigger than the PHP setting ‘upload_max_filesize’? What about the ‘post_max_size’ setting?

While those settings usually default to 64MB or 128MB, I’ve got 3 web hosts: one defaults to 64MB, one defaults to 4MB, and one defaults to 2MB. You should be able to change those settings using the CPanel.

The simple solution would be to change a user’s password to some unknown (maybe random) password, which would force the incoming staff member to go through the “forgot your password” process to reset the password.

Another easy solution, would be to just generate the new password from the existing user profile (when logged in as admin) and give it to the new staff member and tell them to change it the first time they log in.

The more difficult solution would involve developing a user manager interface that understood topics like ‘password age’ and expirations, etc. It could be a plugin that runs quietly in the background every time a user logs in. After so many days, it would expire, or you could set it to immediately expire.

I understand that you want subscribers to see only the articles that they wrote themselves, when they visit the website (frontend). But:

Do people have to be logged in to read articles?

• If not, then your subscriber will only have to log out to read the other articles anyway.
• If yes, then why would anybody author something if they are the only ones that can see what they wrote? (because each subscriber only sees their own, meaning nobody else will see what they wrote).

I’m guessing that you don’t have to be logged in to read, which means #1 above, that they only have to log out to see what you’re trying to hide from them.

You could modify the post template (php) (in your child theme) to include a verification where the current user is not logged in or if they are logged in, they are the author. The WordPress functions: wp_get_current_user() and get_the_author_meta() would probably play a role.

I’m not sure I fully understand your question.

So, let me start with the topic of Google Fonts. Google Fonts are available HERE. Click on any font, click the plus sign, and then open the tab at the bottom. Google’s preferred method of using their fonts is for you to link to them externally. Easy Google Fonts most likely just creates those links for you. You could look for the links in your theme’s ‘functions.php’ file, or as @imports in your style.css. Or more likely, they’re buried in a file inside the Easy Google Fonts plugin. You should see them if you do a view-source:<url> on your page (where <url> is your page’s url without the angle brackets.)

Instead of using Easy Google Fonts, you could download the fonts into your theme.
However:
1) If your user doesn’t have the font installed on their device, then they’ll have to download the font from Google, if it’s a <link> or @import, or from your web server if you’ve downloaded rather than linked to it. Google’s servers are most likely faster.

2) Your localized fonts won’t get updated. Google suggests using SkyFont Manager to manage your localized fonts. This keeps your local, downloaded copy, up-to-date by downloading updated fonts as they’re updated. Unless you’re running your own web server, or are renting a dedicated server, you won’t be able to install the SkyFont manager on the webserver.

I am assuming that you’ve already found the “Publish” button and clicked it without success. It is possible that person who created your website, locked it down, to prevent you from adding pages.

1) Check with the developer and be sure that’s something that YOU can do. If you’re paying monthly by the size of the website, i.e., 10 pages for $X per month, for example, then they might not want you adding pages yourself.

2) Look at the plugins. See if one of them might be blocking your ability to publish a page. Again, you should verify with the developer that disabling any plugins won’t screw up your website, before you deactivate. It’s been my experience that not every plugin deactivates / reactivates gracefully.

You’re welcome @aliag.

What I mean by “walk the website load process” is to pretend you’re the computer that is loading the website. If you have a php debugger (I don’t, but wish I did) it will be easier to step through the load process. Without a php debugger, you’ll have to do it manually — reading the actual .php files looking for a redirect. There’s probably a codex somewhere that explains how WordPress loads itself.

You might actually be able to search for the wp_redirects or http_redirect or header to speed up the process. Redirects can even be issued from javascript.

The information that you show above that you refer to as code, looks like an attempt to hide what it’s doing. All of those ‘0x65,’ translate into letters. For example, ‘0x65,’ is a capital ‘A’. It’s a little bit of Javascript code.

You might be able to take a couple snippets from that code, such as ‘enableLinkTracking’ or ‘setTrackerUrl’ or ‘piwik.php’ and search your website code for it. It might give you a meaningful place to start.

Are you using the WP-Matomo or WP-Piwik WordPress plugin? If you are, I’d start with that one. That code references ‘piwik.php’ which is part of this plugin.

Good Luck!!

You can do it “old school”.

Open your favorite FTP client (I like FileZilla) and download all of your site’s files to a local folder tree. Make sure you maintain the file structure on your local computer. If your old site uses MySQL as its database, use a program like mysqldump.exe (Windows, and included with the MySQL install). Dump the database to a local .SQL file.

Open your FTP Client again and point it at where your new files will reside (usually public_html on Linux) and upload all the files that you just downloaded from the old website to the new website.

DO NOT ATTEMPT TO OPEN THE NEW SITE yet.

Create the new database and login remotely — I use the mysql.exe (included with the MySQL install). Load the contents of your backup .SQL file ( \. c:\path\filename.sql ) onto the new server’s database.

Modify the wp_config.php file on the new web host to point to the new database instead of the old one.

NOW, try to open your old website on your new host.

I had this problem a year or so ago when I first started playing with WordPress. I solved it by increasing the maximum file size that I was allowed to upload. That involves a change to the php.ini file (which you can do through cpanel). Change the ‘upload_max_filesize’ option to be larger than the files that you’re trying to upload. What would happen is WordPress would attempt to upload an image, it would get part way through and then just quit — no error, no message, nothing, just a blank image in the library. After increasing the max upload size, I haven’t had a problem.

No. You don’t need to update it. In fact, if you’re not using it at all, you can just delete the twentyseventeen folder in the wp-content\themes folder and you won’t get notifications.

However, just be aware, that at least in the past — maybe not after Gutenberg’s release — everytime you update WordPress, it will put the twentyseventeen folder back.

I suspect, that after the Gutenberg release, you’ll start seeing twentynineteen instead of twentyseventeen, by default.

Try renaming the ‘index.php’ file located in the WordPress root folder. WordPress needs that file to launch the website. If your website continues to redirect, then the problem is NOT with your WordPress website, per se.

Check your rewrite rules. Check your web server configuration files.

Failing that, it is possible that your website’s DNS entries or the domain itself have been compromised. Your web host and/or registrar can help you track that down.

If the page does not redirect when you renamed ‘index.php’ (don’t forget to rename it back), then I would look at files that do not always get overwritten during a version upgrade. Start with ‘index.php’ and walk the website load process until you discover where it redirects. A file compare tool might help you with that.

Look at your plugins. You’ve disabled them with an underscore (thank you for that, I didn’t know you could do that) prefixed to the folder name. But somewhere in the WordPress core, there is code that recognizes the underscore and deactivates the plugin. Make certain that nothing bypasses that and runs code in a plugin folder anyway.

Depending on how extensive your website is, or more importantly, how much configuration you’ve had to do with each of your plugins — new forms, ecommerce set up, etc., an alternative to tracking it down — since you’ve already disabled your plugins and deleted your themes — would be to back everything up (with FTP, not with a WordPress backup plugin), and dump the database (I like the command-line mysqldump.exe for that in Windows), then delete ALL of the files associated with the website (except the backup), install a fresh, clean copy of the latest WordPress version, install a new theme, and then install or copy each plugin, one at a time from the backup — testing as you go — until you’re back up and running. Any plugins that do not have extensive reconfigures, I would just install from scratch.

Another place to look is the database. Look at the options tables. Look for any values with embedded code. Some may be legitimate, but some may not be.