Dutch van Andel

Are you using a search plugin of some kind? Search results should use the loop, which means they should be subject to filtering by PSC.

There’s only one way I know of that search results might be getting skipped (off the top of my head): and that is if the search results are being displayed in a manner that bypasses the WordPress loop. In that case, PSC can’t function because control has been taken away from WordPress.

Thanks, Noumaan.

You’re spot-on. I firmly believe that post formats are (and should continue to be) an aesthetic component. With that in mind, I think we just need to help end-help users along a bit… and all it takes to achieve that objective is a friendly, helpful UI refresh. ??

Jason,

You don’t seem to understand how caching works.

Here’s the gist version:
When you visit a webpage, your browser caches everything locally. As you browse around the site, it uses it’s locally cached copies to speed up web page load times. There’s no need to re-download everything constantly, which not only hurts the visitor, but places extra load on the server.

Now if you have an image with filename myimage.jpg and then you replace that with something else, chances are your web browser will keep serving up the one it’s cached until you FORCE it to reload it… either by clearing the cache, or doing a force-refresh if your browser supports it.

Developers have some small control over caching by telling the browser how long it should hold on to downloaded files (via headers, etags, etc)… but at the end of the day, a website can’t FORCE a browser to do anything. You can only make recommendations… and some browsers are much more militant about holding onto their cache for the sake of speed (even ignoring “distant past” expires headers).

This has nothing to do with the media manager, this plugin, or anything concerning WordPress… it’s a browser issue. If you replace a file that is already cached, you will need to force refresh the page you’re working on. Eventually it would simply happen on it’s own as the cached file “ages”.

As far as Enable Media Replace is concerned, there’s only one way I know of that you might be able to force a file to update on revision with any amount of consistency… you must change the LINK to the affected media to include a randomized querystring parameter.

For instance: myimage.jpg?1355666742

And then, every time you update that file, you need to update that querystring value (the above example uses a unix timestamp which would theoretically change on each file replace).

While it is technically possible to do something like this automatically with a plugin, it’s a sloppy solution to something that isn’t really a problem.

Thanks, Elizabeth! Your patch works flawlessly.

Hi JMay-Chang,

This is a known limitation currently, and here’s what you can do about it…

The cause:
This happens when ALL the posts for a given archive page are protected. Page Security works by literally removing stuff from the dataset after it’s fetched from the database, but before WordPress can use it (so it’s pretty darn secure).

BUT… when ALL the posts for a given dataset are removed like this, WordPress thinks the dataset is empty, and throws up the “Nothing found” screen… which also has the unfortunate side-effect of hiding the pagination controls (which would let you go to another page containing additional posts). Fortunately, there is an easy work-around…

Workarounds:
There are two ways to work around the limitation until I can get it fixed…

1. Increase the number of posts per page (recommended)The easiest fix is to increase the number of posts that WordPress fetches per page. You can do this by logging into your admin and going to Settings > Reading and increasing (or doubling) the number next to Blog pages show at most
2. Ensure that you pepper unprotected pages into the mixThis is an annoying workaround, but it will work. If you have a lot of consecutive protected blog posts, you just need to ensure that you have a few unprotected ones mixed in. If you’re ‘Blog pages show at most’ limit is 20 (see above), then make sure you include 1 unprotected post after every 10-15 protected posts. This will ensure that WordPress always has something to display.

The next version of Page Security fixes this bug, but my work schedule is so full that won’t be able to finish it up until February at least.

There’s a simple trick that can be used in vanilla WordPress to do exactly this.

Simply add a ?redirect_to=%2F querystring variable to your login links and users will be automatically be redirected to the homepage when they log in.

Example (put this in your href):

https://example.com/wp-login.php?redirect_to=%2F

Note: %2F is the url-encoded version of / (forward-slash). If you have bigger urls, you can encode them with online tools like this.

The accounts are unaffected. Page Security checks account validity with each permissions lookup – so if the expiration date is in the past (based on SERVER time), then the permissions check fails and access is blocked.

This is something I’d really like to do, but I don’t have a lot of time at the moment so this feature is on the backburner. PSC is one of those things that started out as a simple, specific, feature and then outgrew itself faster we could plan, so the next version is a complete rewrite that should make adding features much easier and faster.

Maybe once I get 2.0 out I’ll see if this is feasible.

Thanks for the heads up. I’ll add to the to-do list.

Ok, that narrows things down. If the Media button is doing nothing at all, then it’s a problem with the Javascript. That usually means there’s a plugin injecting some bad Javascript into the page (one piece of bad javascript will halt all Javascript on the page).

Now, that said, it sounds like you might have other problems. Before we do any other troubleshooting, though, here’s what you should do first…

Start by disabling ALL your plugins. Turn them all off.

With all the plugins disabled, see if Media button starts working again. If it’s fixed, start re-activating plugins one at a time, testing the Media button each time you re-activate a plugin. Depending on how many plugins you have, this can be tedious, but it’s the ONLY way to narrow down what’s causing the problem.

If it’s still broken, then disable Adventure Journal by setting your theme to TwentyEleven. If that fixes it, let me know and I can try figure out what part of AJ is causing it.

If the Media button is still broken after all that, then WordPress is corrupt and we can go from there.

Hi ilovelucca,

Image uploads are handled entirely by WordPress. Chances are that there’s either something wrong with your WordPress install (not likely, but still possible), or your server has very restrictive upload settings (most likely).

Are you getting any specific error messages when you try to upload media? What exactly happens when you try? Can you write out a detailed example?

Also…

In order to upload images, WordPress makes use of PHP features that some servers place very strict limits on – like file uploads and script execution time. The first and easiest thing to check this is to look at the bottom of the Media > Add New screen of your WordPress admin. You will see a little piece of text like “Maximum upload file size: 1MB.”

If the images you are trying to upload are bigger than that size, you’ve found the problem. If not, then I’d next try contacting your hosting service to find out if there are any upload restrictions in place.

The plugin foregoes any kind of database direction since a basic understanding of WordPress’s $wpdb object is both a bit of a given and a different topic entirely.

You can read up on WordPress’s database object here: https://codex.www.ads-software.com/Class_Reference/wpdb

While it’s no Zend or CakePHP, it’s fairly easy to get the hang of.

Thanks Jason!

I’ll update the plugin ASAP.

csp673,

Can you shoot me an email at [email address moderated – this forum does not provide support via email]

Q. Is there a concept of “restarting” WordPress, or is that not necessary?
A. Not like a computer. If you decide you need to do a clean install of WordPress, it *is* possible to export the data and import it again. To do that, you would need to do two things first:

1. Make a full backup of your site and db (just in case)
2. Make a backup your /wp-content/uploads/ folder
3. In your admin, go to Tools > Export to export all your data.

Once you’ve done that, you delete everything, reinstall WordPress from scratch, reinstall the theme from scratch, restore your /wp-content/uploads/ folder, then restore your content with Tools > Import. This will give you a “fresh” WordPress install but preserve your blog posts/pages/etc. I would only do this as a last resort.

Q. Is it more conclusive in identifying a problematic plugin by deactivating ALL and reactivating one by one?
A. If deactivating all the plugins solves the problem, then yes.