Can I change a hard-coded link in a plugin?

Thanks, Julian, I'll make a note to keep checking that. As always I appreciate your help!

I'm not personally familiar with that plugin, so I will answer this generically:
#1. Possibly, if the link is stored in the database. You could look at the plugin code to determine which tables it uses, and then look at the contents of those tables. USUALLY a plugin like this would give you an admin screen to manage the links, if it expects you to be able to change them.

#2. Yes, but that is not ideal. It means 2 hits to your web server instead of just 1, so it's more load on your server and a slightly slower experience for your users.

#3. The plugin should not overwrite any .htaccess rules (if it does, then it's a horrible plugin and should not be used, not to mention bad permissions on your .htaccess file). I would not change the code in the plugin itself, since THAT would definitely get overwritten on the next plugin update.

#4. I would first check into the database side of things. There are lots of ways to change content, but that doesn't mean they're the RIGHT ways to change content. Your best bet is to see if the plugin uses the database for storing links, and assuming it does, change it there (ideally through the plugin admin, but you can try direct update and MAYBE it would work).

I'll also add that if what you have is just an example of more, then you also have to consider that you have to maintain all these rules in the .htaccess file (e.g. "portfolio/ix-systems" => "ix-storage").

If that's the only one you have to redirect, it might be marginally acceptable, but it's a really bad precedent. ANY error in the .htaccess file at all will break the entirety of your site until that error is fixed. So if you miss a quote and it takes you a few minutes to find it (or worse, you make a breaking change at the end of a long day and head off to bed without testing, leaving the site broken overnight), then it's just bad news. So the more times you have to make changes to .htaccess, the higher the risk.

To add a few more things to that:
1. The .htaccess file is Apache-specific, so if you ever change web servers in the future (e.g. I'm seeing more and more people switch to Nginx in the past couple years) , then your redirects would break until the web server configuration was fixed.

2. The .htaccess file is read on every single page or file access, whether it's an image or a page or a Javascript file or a stylesheet. So the more rules you add into .htaccess, the more impact it has overall on every request. Again, a small handful of redirects won't have a big impact, but it's not a good precedent.

Best option is really to try for the database route. It would be faster, more efficient, portable/compatible with any web server, and most importantly, much lower risk.

One more thing you could potentially do (if the plugin license allows it) is just duplicate that plugin under a new name and become the new "owner" of your version of that plugin. You almost certainly wouldn't be allowed to share it publicly (it would be akin to taking credit for someone else's work), but you could make whatever changes you need directly to the code. And since it would be your plugin, you wouldn't be updating it anymore from the main plugin repository (so you would be solely responsible for maintaining that plugin copy from that point forward).

Thanks so much. I'll check the database, and maybe go that route. Again, updating the plugin won't overwrite those links though, is that right?

It really depends on how the plugin works. It's unlikely, but not impossible.

The problem with the DB route is if the Plugin updates the database on save of its data you lose the changes you made. Also, how are you going to do the updates - with a query? How is the risk of spelling error or similar any different in this scenario than the .htaccess route?

So for instance if you go into the admin and edit the IX settings and save - you now have to go back and change the database afterwards. The risks here (in my view) are far higher than those that go with the .htaccess.

If your structure is going to be consistent then you can setup a generic rule that uses regular expressions to craft the destination URL - which eliminates the need for maintaining multiple links.

I suspect I might be missing something here as I cannot see the up side on manipulating database entries created by a plugin
a) what is stopping the plugin overwriting the changes
b) What mechanism are you going to use to update the links - unless you write your own plugin to manage the links so that it runs after the save operation on the current plugin completes.

How is the risk of spelling error or similar any different in this scenario than the .htaccess route?

Significantly different. A typo in a database value might break that link, but the rest of the site would still run (at least it should, if the plugin is coded correctly). A typo in .htaccess could break the entire site if Apache can't parse it (depends on where the typo is).

So for instance if you go into the admin and edit the IX settings and save - you now have to go back and change the database afterwards

Again, depends on how the plugin is coded. Most plugins that deal with lists of items won't try to re-create or re-update every piece of data in the table, because it doesn't scale well. I haven't looked at that plugin, so I don't know if this one does or doesn't - I'm just speaking generally.

I suspect I might be missing something here as I cannot see the up side on manipulating database entries created by a plugin

Honestly, a good plugin should provide that access so there's no manual manipulation. If it were me, I'd just as soon as find another plugin if it didn't meet all my needs or forced me to take drastic measures. Anytime a plugin pushes me to make changes to .htaccess or directly modify the database, I'd consider those all to be drastic measures that disqualify all but the most valuable plugins.

But in this case, I'm presuming that the OP wants to stick with this plugin, so I'd say that the database manipulation would be the safest (but more manual) approach.

Alternatively, there are search-and-replace plugins like this:
https://wordpress.org/plugins/real-time-find-and-replace/

...which could also solve the problem, albeit in a not-very-performance-friendly way (output buffer replacement). If such a plugin was used, at least it would provide an admin interface for safely managing the replacement rules without ever touching .htaccess or relying on it.

A typo in .htaccess could break the entire site if Apache can't parse it (depends on where the typo is).

It's called testing - you get the URL working - fix the typos and never have to touch it again. Database changes are happening all the time ipso facto higher risk.

Again, depends on how the plugin is coded. Most plugins that deal with lists of items won't try to re-create or re-update every piece of data in the table, because it doesn't scale well

That is not what I was saying but it doesn't matter either way - even if it only updates one of the items - that item breaks immediately. Once you have the .htaccess working you can't break it short of changing the Plugin code to generate a different URL.

Honestly, a good plugin should provide that access so there's no manual manipulation

Did we agree this was a good plugin or were we looking for a work around on how to fix the URL's in a plugin that does NOT provide that functionality.

Just so I understand - you are advocating a solution that requires a manual change to the database every time a Portfolio item is added or changed and claiming that is better than a once off never changed again .htaccess rule?

Sorry but I don't get it - can't see how the database option is better?

It's called testing...

Exactly. Testing, which implies that mistakes can be made. And during testing, mistakes can cause the entire site to be down.

And let's say that's not the only change they make. Once someone gets to using a "tool", they often start using it for later changes, too. So that's more testing and more possible downtime.

.htaccess is a critical file that can make or break the entire site. It's not something that should be used for content-specific patches.

I'm simply advocating a solution that doesn't involve modifying a highly-sensitive file that can not only bring the entire site down (and cannot be safely tested without the use of a second mirrored site), but also impacts the site portability and also impact the performance of the request and also impact the performance of EVERY request to the site.

At least with the database option, mistakes, updates, and rework is localized to the plugin.

It's not a great solution, but it's a safer solution.

If it were me, these would be my options in order of preference:
1. Find a different plugin.
2. Duplicate and modify the plugin (if allowed)
3. Use a search-and-replace plugin.
4. Modify the database.
5. Modify the .htaccess file.

Sorry, one more possible solution - see if the plugin exposes any filters/hooks that you can use to modify its generated content via another custom plugin.

Just to jump in, if anyone can tell me about a plugin that does this:

1. Filterable
2. Grid
3. Customizable link

I'd be happy to look at it. I've searched for some time and found only this one, which doesn't work on my version of WordPress, sadly: https://wordpress.org/plugins/responsive-filterable-portfolio/  - there is no add a portfolio option.

Interesting discussion, thanks again. I think I'll stick with the htaccess solution for a few reasons.

1. I don't have the skills to alter a plugin
2. It's a website in the making, so if I make a mistake on the htaccess, I'll just upload the backup and fix my mistakes.
3. It's only a handful of urls.

It's only a handful of urls.

I would investigate implementing a single rule in your .htaccess which can handle all instances of redirect.

There are two reasons for this
1. It makes for a cleaner and leaner .htaccess file - too many routes is, as Gr8gonzon pointed out, not ideal
2. It removes the requirement for making changes when you add / remove a new portfolio.

ok, thanks.