Lmst

Foster kittens fighting with #mod_rewrite.

@twinkelicious

Ich habe immer versucht vieles ohne irgendein Plugin zu machen.

Jetzt kommt es auf deinen Webserver an.

Ist es ein Apache, kannst Du das Redirecting and Remapping mit #mod_rewrite erledigen.

Da kannst Du hinterlegen was passiert wenn irgendwas aufgerufen wird.

Bei Dir, dass Bild wird angeklickt und die Webseite wird aufgerufen.

Das schöne daran ist, es ist eine Text Datei.
Da gibt es viele Möglichkeite das zu Automatisieren.

https://httpd.apache.org/docs/2.4/rewrite/remapping.html

Can someone please explain to me why an Apache mod_rewrite rule would apply in Chrome, but not in Firefox? Basically, I'm taking the requested subdomain, e.g. [something].mywebsite.com, and using that string to 301 redirect to mywebsite.com/[something]. Works perfectly in Chrome, but hasn't worked in Firefox in a while (first version worked in both, but I had to reimplement it after a WordPress update overwrote it) and I have no idea why that should be a thing. We basically have zero Firefox users attempting to use the subdomain aside from myself, so it doesn't *really* matter, but I just want to understand (and avoid an unnecessary customer service email in the event that a Firefox user scans the QR code and erroneously ends up at the homepage; yes, the subdomain was a mistake. But the QR codes are out there by the thousands, so it's too late for me now lol).

I should say that the majority of my mod_rewrite experience was probably a decade or so ago, so I'm definitely pretty rusty.

The rule:

RewriteCond %{HTTP_HOST} ^(?!www\.)([^.]+)\.(mywebsite\.com)$ [NC]
RewriteRule ^ http://%2/%1%{REQUEST_URI} [L,R=301,NE]

#apache #mod_rewrite #server

So this should get rid of the bots:

# Deny bots
RewriteCond %{HTTP_USER_AGENT} "[Bb]ot/|meta-externalagent"
RewriteRule .* - [G]

#apache #mod_rewrite

This is where I am w/ the github repo @zombiewarrior

It's really close to being "right", so to speak.

compare that to e.g.
http://statecollegeguitarlessons.com/adb/index.php

Note: my server is #LiteSpeed and i don'[t mess w/ it. But, that should not have the /public/ in the URL. If you've ever worked w/ #laravel it's like the ./index.php of the proj dir there. where there's ./index.php "reditrecting" to ./public/index.php
but you need to mod the #NGINX server {} location {} stuff for the... mod_rewrite type stuff.
i.e. the URL should be .com/giterator/ , accomplished in nginx w/ "@alias"
(sans the ./public part). you see the same thing either way. pet peeves.

EDIT: ALSO! CORRECTION -do NOT see the same! ARGGH! w/out that #mod_rewrite bit #htaccess whatever!~ the #CSS #asset paths mess up as well. Prob explains the missing SVG (masthead.php) forgot about that. oh well. hey. gimme a damn break! brain damage!
SEE "new" version here, ( i can fix that path thing. i forget the quick path top of my head momentarily. i prefer to be correct instead, anyway!)
this is NOT correct! http://statecollegeguitarlessons.com/giterator/public/index.php

first time w/ the #namespace #php8 #composer #autoloader #PSR4 #MVC #refactoring.

i must admit, it was more challenging that i expected.

but yea. feel free to hop in there at any time, and help me polish that old turd already!
Sheesh!

elements of adbiterate require fixing debugging something

@mook @MastodonEngineering EXACTLY THIS is why I think a "#Webhoster-only" functional #ActivityPub server is kinda important.

And if #Mastodon was that, I could understand them saying "#canfix & #wontfix" for all the valid reasons (tho I'm shure #PHP devs fluent in #mod_security & #mod_rewrite would likely disagree!)...

And for what Mastodon does, it feels quite overengineered and overcomplex, but then again I'm used to #MkDocs and other, "#offline-#CMS|es" that do just work and are kinda essential for stuff on @torproject / #Tor because noone there uses #JavaScript and enabling #JS is discouraged by #TorBrowser for all the right reasons...

I should take a closer look at #streams once I have time for that...

Earlier this month I noticed that a particular bot that likes to visit my website, “MJ12bot/v1.4.8” seems to be particularly attracted to the “reply to comment” links generated by my blog. Those are links that bots see, but we see the “Reply” button that uses JavaScript to reply to a comment.

To be honest, it’s pretty annoying to see a bot constantly fetching those URLs from my website. Earlier this month, it was on a roll and grabbing several dozen at a time. While my server can handle the traffic without any issues, who wants a bot trampling over their server?

I decided to stop them in two ways:

Redirect them back to the post in a mod_rewrite rule.Block them in robots.txt and hopefully the bots will go away.

Coming up with a mod_rewrite rule was surprisingly hard, but after mentioning this on Mastodon I received a reply from Jos Klever who figured out I needed the QSD flag. So, to spare you the hassle of researching it, here are the mod_rewrite rules that worked for me. It causes a 301 permanent redirect to the anchor tag of the comment.

RewriteCond %{QUERY_STRING} replytocom=(.*)$RewriteRule ^(.*)/ $1/#comment-%1 [NE,QSD,L,R=301]

Blocking requests like this in the robots.txt is much simpler. WordPress can generate the robots.txt file for you using the robots_txt filter. Add the following to a mu-plugin PHP script.

function disallow_replycom_urls( $output, $public ) { $output .= 'Disallow: ?replytocom'; return $output;}add_filter( 'robots_txt', 'disallow_replycom_urls', 10, 2 );

I haven’t received many comments on my posts lately. However, I stumbled upon some interesting posts by clicking the RANDOM link above, which I decided to examine as part of my research. During my search, I delved deep into the blogosphere of the past, almost like being an archaeologist, because some links were no longer available, and I had to search for them on archive.org. I was also pleasantly surprised to find that a link to a GIF from 2005 was still alive!

#mod_rewrite #robots-txt #wordpress

https://odd.blog/2023/02/27/redirecting-replytocom-so-bots-go-home/