timondavis

PS MAMP is the quick and dirty way to get things done. For a more sophisticated setup, I recommend getting started with Docker. Docker makes virtual Linux environments on your Mac machine and lets you run websites like its running on linux. It does a lot more than that too.

The main benefit, however, of using something like Docker, is that messing with Docker’s virtual machine settings won’t mess with your Mac’s settings, which can get painful over time.

Strongly recommend this for reading:
How to install Docker on Mac: https://docs.docker.com/mac/step_one/
How to install wordpress on Docker: https://docs.docker.com/compose/wordpress/

Good luck!

You’re installing this locally on your mac? If so, read on…

First off, you need to be aware of the LAMP stack… LAMP stands for

L inux
A pache
M ySQL
P HP

Which are the technologies which drive your a wordpress application. Linux is the operating system. Apache is the ‘server’ which is responsible for taking internet requests and sending info from your site back out to the requestor machine. MySQL is the database technology used to store site information. PHP is the language which handles the logic.

The reason I’m explaining this is because, in most cases, LAMP is what drives wordpress. However, you don’t have a linux machine, you have a MAC machine, so LAMP won’t work for you – you need MAMP.

Anyhow, you can download a MAMP stack (Mac Apache MySQL PHP) for Mac. This is the -simplest- solution, you can download it here: https://www.mamp.info/en/downloads/

This article explains how to install wordpress with MAMP: https://theme-fusion.com/local-wordpress-installation-mac/

Yep, you’ll probably need to start over with your installation… but if you consider this a learning experience, then its great exercise ?? Let me know if this helps or not.

* Edited to attempt a little clarification

Thanks for the update @reed1256

It’s tough to say, exactly, what the issue might be – I don’t have the cash to drop on purchase of the theme at the moment. It may be worth reaching out to the support people about for the salient theme about your issue, btw, if you paid for it it comes with 6 months support from themenuclear.

Still, there’s a couple of things to verify that I found after some googlin’ from the official documenation for the theme and its intended use: https://themenectar.com/docs/salient.pdf

1. From the manual:

Home Slider – Allows for a quick slider to be automatically placed at the top of the home page (as long as a home template is selected in the page attributes box.)

2. Video Tutorial Series! https://www.youtube.com/user/ThemeNectar

Apparently, there are some videos about using the slider here.

That’s about all I can suggest without being an admin of the site to see the problem for myself, or otherwise be able to reproduce the issue on my own machine. Hope this info helps, let me know if I can answer any other questions that might help you track the main answer down.

Try
echo '<pre>' . var_dump( $yourcat ) . </pre>;
to output the variable to the page.

Use
is_string( $var )
to get a TRUE or FALSE value back as well

https://php.net also has some other great search tools which will help you fish out various random helpful functions ??

#logo {
    position: absolute;
    top: 20px;
    z-index: 10;
}

It looks like #logo img was set as absolute, you may be trying to do the same thing I am, but the position: absolute rule doesn’t have a semi-colon, so it was ignored ?? I recommend targeting its parent container (#logo) anyhow.

Also, the container is going to need the boost to the z-index, the image will go up with it.

Also, possibly a silly question..

Have you confirmed that the $yourcat variable is a string, as opposed to an object?

GREP!

https://www.cyberciti.biz/faq/howto-use-grep-command-in-linux-unix/

Use the linux grep command to hunt down that undefined index “sense” – that will give you a list of files which contain the word ‘sense’.

From webroot/wp-content:

grep -rni sense *

Of course this will only give you a few clues as to where the error might be, but its a start ?? Good luck – let us know if we can help you any further – or, of course, if this solution isn’t viable.

Hrrrm, sounds like an issue with the theme, unless you’ve done any custom modification yourself? If this is something to do with the theme, I see two immediate options in front of you:

1. Does the theme you’re using declare that its compatible with your current version of wordpress? If so, contact the author of the theme. If not, see #2 (or pick a different theme that _is_ compatible)

2. Try updating your CSS. This is HACKY – just a band-aid to help you so you can move forward, but I don’t generally recommend you do something like this unless you’re already familiar with CSS. That said…

1. Get the color code for your desired color. Go to https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Colors/Color_picker_tool and use the colorpicker to select your desired background color. Copy the HEX value for the color from the box on the bottom right of the selection tool (should look something like #FFFFFF or something along those lines).

2. Find the style.css file in your theme directory ( [siteroot]/wp-content/themes/[your-theme-name]/style.css ). Most themes _should_ have that file in place, though not every one. You might have to fish if that file doesn’t live right there.

If there is a rule along the lines of…

body {
background-color: #eeeeee;
}

or

body {
background-color: rgb( 240, 240, 240 );
}

You’re going to want to change that value so that your color from step one is the value. So if you update this, it will look something like

body {
background-color: #FFFFFF;
}

If you can’t find anything like that, try just copy-pasting the same structure into the top of your stylesheet.

However! CSS works based on the principle of specificity, and my guess is there’s a rule more specific than the above governing your background color. You’re likely going to need to get more specific. Try these in order, until you get what you need…

body {
background-color: #FFFFFF;  (or whichever color you want in there)
}

html body{
background-color: #FFFFFF;
}

html body.page {
background-color: #FFFFFFF;
}

If this still isn’t working, open up your inspector in chrome and search for “body”. Try applying classes or IDs as appropriate. You’re getting to need to know a bit more about CSS than what I’m covering here at this point, but you’ll find some great guides here: https://www.w3schools.com/css/

Let me know if you have any luck – or find a simpler solution ??

It sounds like you have the right idea with regard to your page structure. With the .php extension on pages, there’s a bit more of a conversation there… WordPress really isn’t going to accommodate the .php extension, to the best of my knowledge. Still, you’ve got options.

The simplest (as in ‘least technically demanding’) option that springs immediately to mind which may be of help, both of which revolve around the 301 redirect. While I’m more of a developer than an SEO expert, my understanding is that 301 (Permanent Redirect) plays fairly nice with SEO when a url has changed – I verified this idea here: https://moz.com/learn/seo/redirection

Here’s my most immediate suggestion: Use the Redirection Plugin

1. Install the above plugin
2. Proceed, from the dashboard, to Tools -> Redirection
3. Click the ‘Redirects’ tab/link near the top of the page
4. Begin plugging in the source URL and the target URL. In your case, the source url would be the one ending in .php, and the target would be the wordpress version of the same post. You’ll have to create a new rule for each legacy page you want to accommodate, though it looks like the plugin will also let you use regular expressions if you want to go that route.

Is this helpful to you?

First thing to check is that the files and directories in your install (as well as the root directory itself) are readable as appropriate.

From https://codex.www.ads-software.com/Changing_File_Permissions:
All files should be owned by the actual user’s account, not the user account used for the httpd process.
Group ownership is irrelevant, unless there’s specific group requirements for the web-server process permissions checking. This is not usually the case.
All directories should be 755 or 750.
All files should be 644 or 640. Exception: wp-config.php should be 440 or 400 to prevent other users on the server from reading it.
No directories should ever be given 777, even upload directories. Since the php process is running as the owner of the files, it gets the owners permissions and can write to even a 755 directory.

Read more on the link page from www.ads-software.com for further details

It also may be worth a quick check of the .htaccess file in your root directory, assuming that apache is your server (it typically is). Look for any lines that have the actual number ‘403’ in them.

(ignore this – I forgot to click the follow-up emails box so I have to snd up a new post to catch replies ??

It could still be a file/folder permissions error – I’ve definitely seen some installs where the core directory permissions are configured differently than the wp-content folder, where all of the plugins, themes and uploaded media live.

It sounds like the path to your document root may well be /var/www/html/ – that’s a very common path for a webroot, especially on an Ubuntu box. Have you tried updating the permissions on that directory and trying again? If you attempt this, you should probably keep track of the permission of the files and directories in the root directory, as well as the wp-content directory, so you can reset them to their original settings if needed.

For the sake of fun, here’s a heapin’ helpin’ of file permissions info, straight from the official wordpress site: https://codex.www.ads-software.com/Changing_File_Permissions — giving this a read may be worth while if permissions are indeed your problem. Plus it will tell you what your permissions should be, and why.

In case the above doesn’t work out – would you mind sharing whether you’re controlling permissions via Terminal, FTP Client or cPanel?

Perhaps I’m missing something – I’m not quite clear on how you’re uploading the ‘home slider’. Could you point me at which theme you’re using, and the specific steps you’re taking to apply the image?

Hi 007dutchy,

I used the chrome code inspector to look at the page you posted – odd indeed! I can see that the URLs being used for the images are just fine (in fact I can preview the images by mousing over the ‘src’ attribute of the image tag), so the assets are definitely accessible to the public. I’m also seeing that there’s a jQuery error: “Uncaught Error: Syntax error, unrecognized expression: a[href^=#]”

While I can’t say for sure without downloading the theme and reproducing the error (the theme costs $59, which is exactly $59 out of my budget! ?? ) My first instinct is that the theme itself may be the issue – if jQuery got updated (I’m not sure if you upgraded from a super-old version or from the most recent version) and the Sahifa theme wasn’t updated to keep playing nice, jQuery might not like the requests that Sahifa is making. It could also be that updates to 4.5 are causing the JS generated by Sahifa to be malformed. I could also be a bunch of different things I’m not bright enough to imagine ??

Again, this is purely speculation. Still, it may be worth reaching out to the good folks at Tie Labs and ask them if there’s anything they can do to advise. I noticed that they claim compatibility only up to WordPress 4.4.2. It could simply be that you need to revert to 4.4.2 until they have an offering which is compatible with version 4.5

From what I’m gathering from your question, you’re essentially looking to block robots from scanning your site for user info by spamming author URLs. Is this correct? If so, here are two options for you to consider:

1. iThemes Security Plugin https://www.ads-software.com/plugins/better-wp-security/ (recommended)
Along with a bevy of additional security features, this plugin features an option which will block author pages from being served from your website. This rule isn’t absolute, however; If the author in the query actually has content on the site, then the page will display the typical expected output. The plugin only prevents reads on authors who have _no content_ attributed to them on the site. I’m guessing this is what you might be looking for.

To apply this solution:
1. Install the plugin from https://www.ads-software.com/plugins/better-wp-security
2. Activate the plugin
3. Proceed to (from the Admin dashboard) Security -> Settings
4. Scroll down to the bottom of the page and click on the Disable Extra User Archives checkbox
5. Click on the “Save All Changes” button at the bottom of the page
6. Test

I tested this out on my local installation, which is on WP 4.5, and it worked as described.

2. .htaccess
This option is a bit more atomic: If the request contains the phrase ‘author=X’ in the query string (where X is a user ID), the site will serve up a 403 (forbidden) response. This will ensure that any requests invoking an author are soundly rejected, every time.

To apply this solution:
1. Open up the .htaccess file, located in your site’s root directory
2. Add the following to the bottom of the file:

# BEGIN block author scans
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} (author=\d+) [NC]
RewriteRule .* - [F]
# END block author scans

3. Save the file
4. Test

Like the first solution, testing proved this solution as valid (at least for me)

I got this solution from wpbeginner – you can find the full post here if you want more information: https://www.wpbeginner.com/wp-tutorials/how-to-discourage-brute-force-by-blocking-author-scans-in-wordpress/

Please drop a line and let us know if I’m answering the right question, and if the solution worked for you.