php

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-08-28

Final complete day: 2026-08-28. Attention was 0.9% — this entity appeared in 22 of 2,594 analyzed posts/comments in the seven days ending that day (28 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-08-28 19:57 UTCComment

   the thing that unlocked this for me when i did a similar move: nameservers and redirects aren't really "which first", they're on different tracks. redirects live on the new host, so they physically cannot do anything until dns is already pointing there. but you write and test them before you cut over. order that works: 1. finish the site on the temp domain. don't touch dns while anything is still broken. 2. let the registrar transfer fully complete first. doing a transfer and a nameserver change at the same time is how people end up locked out for 48h with a dead site. 3. drop your dns ttl to 300 seconds a day or two before cutover. default is often 24-48h, and that's the difference between a 5 minute switch and two days of half your visitors hitting the old box. 4. build your 301 map now, on the temp domain. this is the big one for you - a decade old custom php site going to wordpress means basically every url changes (article.php?id=44 to a pretty permalink). for a peer reviewed journal those old urls are cited in other papers and indexed. if you lose that mapping you lose the citations. dump every old url, map each one to its new home, test them on temp. 5. content freeze on the old site, final sync. 6. point the nameservers. 7. ssl after dns resolves, not before. lets encrypt validates over http, so it can't issue until the domain actually points at greengeeks. 8. keep kualo alive and paid for another month. it costs you almost nothing and it's your rollback. also since the domain isn't changing, you do NOT need change of address in search console. just resubmit the sitemap after cutover and watch the coverage report. honestly the 20 pages of notes feeling is normal, the list above is really the whole thing. one step at a time.

2. 2026-08-28 16:17 UTCPost

   Kualo to Greengeeks - nameservers or redirects first? - Need serious help - migrating peer-reviewed journal - I'm at the end of my tether here. I'm singlehandedly trying to revamp an old custom html/php site (a peer-reviewed journal that's been running for a decade) hosted on Kualo and move it to GreenGeeks with a WP installation. The site is on a temporary domain (no SSL) and is basically finished. I got the domain transfer today. But I have no clue what I'm supposed to do next. I have 20 pages of notes. I know my way around plugins, CSS, etc. But I simply cannot figure out what order to do the major steps in... I'm genuinely exhausted. All I can do is give you these notes: * Let the domain transfer finish in the background (takes a few days). * Update Nameservers & SSL: * Update domain nameservers to point to GreenGeeks. * Turn on SSL certificate * Run Better Search Replace for all database urls * Set Up Redirects * SEO * Turn off maintenance plugin " 1. Point the nameservers to GreenGeeks. 1. Wait for ecologicalcitizen.net to reach your GreenGeeks site. 2. Get SSL working. 1. Make sure works properly. 3. Change WordPress to the real domain. 1. In Settings → General, change both WordPress Address and Site Address from the temporary URL to 2. You may be logged out; log back in using the new address. 4. Run Better Search Replace. 1. Use it for the remaining temporary-domain references and other internal URL/path changes in your database (PDFs, artwork, images, etc.). 2. You don't need it just to change the WordPress Address/Site Address. 5. Set up your 301 redirects. 1. Do this while Maintenance Mode is still ON. 2. This handles old URLs that have changed/disappeared, including the relevant old article, author and PDF URLs. 6. Check the site. 1. Make sure the new pages, images, PDFs, links, etc. work. 7. Go live. 1. Turn off Maintenance Mode. 2. Allow search engines to index the site. 8. Test old URLs. 1. Check that important old URLs redirect to their new destinations rather than producing 404s." I need to redirect thousands of URLs so I already have loads of rules written out in a document, with some idea what do for regex syntax... e.g., Regex: /what-is.php?... → /definitions/ This is blindingly complicated. I simply am beyond my capabilities here. I thought the above plan was fine, but it's not because apparently you can do the redirects first by using relative paths. Also, if you do nameserver changes first then surely everyone will get 404s. I seriously need help. This is a collossal task. In fact, if I can't do this, an entire journal dies, along with my livlihood.

3. 2026-08-27 18:12 UTCComment

   Been working with WP since its inception. After approaching this problem many times as you describe, I now just immediately move to scorched earth and hand-rolled custom theme. LLM's make it too easy to transform data to not just immediately move it into a clean install and rebuild theme from scratch. I also don't use plugins, functions.php (unless I have to do like MIME-type acceptance or other core unavoidable tasks), or any of the other onboard features. Just ACF and custom theme and I generally build the theme out in a little CI/CD build script I wrote in Node a while back to replace an earlier Gulp process. The really perverse thing I do is that I use Pug with PHP, which is a super weird barely supported flavor of Pug that produces a set of templates that build themselves on the fly and therefore make no calls back to the server for header or footer; each page is complete the partials are in the codebase as pug files. I don't have a lot of live clients anymore this work has dried up for me but if you are curious here is a repo and example site from an old now defunct client. I think this approach annoys a lot of WP devs. It's basically removing Wordpress from Wordpress is order to make it performant and secure. It also puts the client experience on rails hard; there is no builder support here I think they lead to bad websites. Also the lighthouse scores kind of speak for themselves. In any case I am not expecting people to love it but it is an approach that worked for me for a long time. I designed it to handle change requests and function within a reasonable source-control paradigm. Primarily used it to manage very large corporate marketing sites that got a lot of attention from stakeholders.

4. 2026-08-27 12:37 UTCComment

   When MAMP dies out of nowhere it is usually the Apache or MySQL port being taken by something that updated overnight, so check the error log and whether the ports are already bound. If you want it to stop happening, a small docker compose file for php and mysql is a couple of hours of setup that never breaks on an OS update.

5. 2026-08-27 12:19 UTCComment

   true, i forgot about that one. the info tab already shows most of my list - sizes, plugins, php version. but it will not tell you about cloudflare or a cache sitting in front of the site