wpismypuppet

The only way you’ll be able to “restore” the media is to restore your WordPress database back to a time before you were hacked… Otherwise you’ll have to re-upload all the images and assign them to the correct post.

Once an image is deleted, it’s “permanently” deleted according to WordPress. The fact that you still have them in the upload folder is a good thing! But the database records that point to, and associate, the media files are gone, and those can only be replaced with a database restore, or re-establishing them via re-upload.

Well, that test wouldn’t work, right? Cause you have a custom taxonomy called “section”. Change “glossary-sections” permalink to something completely unique and see if you can access the page that way.

Do you have a custom post or custom taxonomy that shares the slug “glossary-sections” by any chance?

So to get this straight… you have a physical page with a slug called “library”, a child page with a slug called “glossary-section” and a custom taxonomy where the terms will display as “library/glossary-start-here/[term-name-here]”, correct?

And you want to be able to see a page called “library”, a taxonomy archive called “glossary-section”, and when any term is clicked, a taxonomy term page called “/library/glossary-start-here/[term-name-here]”??? Is that correct?

It’s a restriction in PHP, not WordPress. The best solution is if you have access to php.ini, make the following changes:

memory_limit = 32M
upload_max_filesize = 10M
post_max_size = 20M

This, of course, depends on your hosting company. Most don’t allow direct access to php.ini, but offer alternative solutions to change just those values you need to alter. You’d have to check out your hosting company’s policy.

You can also try to add this info into the .htaccess file by adding:

php_value upload_max_filesize 10M
php_value post_max_size 20M
php_value memory_limit 32M

But most hosting companies will restrict users from using .htaccess to modify php.ini information. Check with your host on the best solution, but these are the only two options.

By default, child pages do not show up in WordPress menus… most of the time, parent pages won’t show either unless you click a checkbox telling them to. Try going into “appearance”->”menus” Do you have a menu set up there? Maybe more than one?

If you do, find the primary navigation and see if you can manually add a child page. On the left side, you’ll see a box called “pages” and by default it’s on “most recent”, which annoys me 🙂 Change that tab to “view all” and see if your child page is listed. If it is, check it, then click “add to menu”. Simply drag and drop it where you need it.

If you want it as a child to a parent link (i.e. a drop down), then when you drag and drop under the parent, drag it slightly inward (to the right) until the dashed border shows it indented.

See if any of this helps… let me know what you find.

Hmmm… I’m having trouble visualizing what it is you are trying to accomplish. In the admin area, you are under “Pages”. Then you make a new parent page… and that works. Something like http://uphypnosis.org/classes/.

Then you add a new page as a child to “classes” called class1 for example… so you should have a link like http://uphypnosis.org/classes/class1/.

And this is where you are having an issue? This new page, http://uphypnosis.org/classes/class1/, shows a 404 or something? Am I on the right track?

Unless you have a direct connection to your remote server through a mapped drive, it is impossible to tell WordPress to look at a different server to upload images. So, yes… you would have to first copy them down to your local machine and then upload them to WordPress from there.

The only other solution would be if you could remote desktop the remote server and get on the internet from it… then you could log into WordPress from the remote machine and browse the files no problem.

Theoretically speaking… let’s pretend that you have the remote server mapped to your local machine. If you were to have WordPress access those file and upload them, those files would still be “copied” to your local machine and then uploaded to WordPress from there… it would just be more transparent to you… but there would never be a “direct” connection from WordPress to a remote machine… only the machine you are using to log into the admin area.