meta user
network profile
| bio | website | artlung.com |
|---|---|---|
| location | San Diego, CA | |
| age | 43 | |
| visits | member for | 2 years, 9 months |
| seen | May 15 at 19:30 | |
| stats | profile views | 60 |
I am a web developer and some-time designer, blogger. Tech interests: PHP, MySQL, JavaScript, especially OO, jQuery, Flash, Open Source libraries of all kinds, WordPress, SilverStripe, Drupal, and more. I like to make web things.
You can reach me at joe@artlung.com
On twitter @artlung
See also: joecrawford.com
|
Aug 8 |
comment |
Members Only site with Feed Keys This is working great, thanks! |
|
Aug 7 |
comment |
Members Only site with Feed Keys Thanks @bueltge, I'll take a look soon! |
|
Aug 4 |
comment |
Members Only site with Feed Keys Thanks @bueltge I could just as easily fork Members Only and fix the Feed Keys aspect, but, yes good point! |
|
Aug 3 |
comment |
Members Only site with Feed Keys I'm really hoping for a solution which does not require storing site authentication information in the feedreader. Without some alternate way, like with feedKeys, your solution is not good enough. |
|
Jul 31 |
comment |
Members Only site with Feed Keys Is there a mechanism for allowing Feed Key based "authentication"? |
|
Jul 31 |
comment |
Members Only site with Feed Keys So the authentication occurs with HTTP Auth then, users will put in username and password for their feed then? Is that right? Is this compatible with online feed readers such as Google Reader? |
|
Jul 31 |
comment |
How do I turn off self-closing tags for markup in WordPress (for HTML5, or HTML4, for example)? @Ricky55 In the end self-closing tags ended up not being an issue for me and I went with just leaving them. |
|
Jul 24 |
comment |
Exclude Tags from get_the_tags @DustinJ glad to help! |
|
Jun 23 |
comment |
“Donate to this plugin” for WordPress.org Plugin Authors Awesome! Thanks @moraleida! |
|
Mar 16 |
comment |
Getting rid of files not used by latest upgrade Can you list some filenames of such files? |
|
Mar 16 |
comment |
Local copy of WordPress Codex? This is a great lightweight way to quickly save a large group of files. I was hoping for self-contained, but I've been testing this since I opened the bounty and this is the easiest quickest way to get a local copy of the relevant docs. |
|
Mar 14 |
comment |
Local copy of WordPress Codex? @EAMann actually I know a few folks using IIS but I take your point. I will say again that the instructions linked to lack detail. There's no "recipe" created to actually run the backup. |
|
Mar 13 |
comment |
Local copy of WordPress Codex? This is pretty great. Is there a way to feed it a list of urls to capture for later viewing? And is there a way to say "go refresh this list of urls"? |
|
Mar 10 |
comment |
Local copy of WordPress Codex? Is it possible to store into a static set of html, or do I need to be running Apache/PHP (or whatever current MediaWiki requirements are) on the target device? The Implementation details lack a simple set of instructions, they instead point to other solutions in various stages of completeness. sciencemedianetwork.org/wiki/… |
|
Mar 9 |
comment |
Side effects of disallowing *.php requests in production environment? wp-admin is indeed removed. database is indeed firewalled. whole site has a load balancing infrastructure in front of it with intrusion detection included. |
|
Mar 9 |
comment |
Side effects of disallowing *.php requests in production environment? Yes, I've looked at some of the plugins we're using and we appear not to be using anything that has a "public-facing" .php file. I'll have to look at all of them a bit closer. Thanks for the coherent answer! |
|
Mar 9 |
comment |
Side effects of disallowing *.php requests in production environment? "If you code correctly, simply calling a PHP file is not enough to hack your site" yes, but WordPress and plugins are third party code. Saving to static files is not a bad idea, but for a site with a great deal of content, this has a different downside, that of a much larger file to be replicated. I appreciate the thought though. Ultimately most people are finding the premise of my question bizarre. :-( Hah! So bizarre someone felt the need to downvote. How helpful! |
|
Mar 9 |
comment |
Side effects of disallowing *.php requests in production environment? @Wyck, I assure you we have operations people who understand security. They deal with tens of thousands of concurrent connected users and devices continuously in other parts of our business. This is the real deal. What I'm trying to understand it myself, thus the question. :-) |
|
Mar 9 |
comment |
Side effects of disallowing *.php requests in production environment? @Steven, yes, AJAX calls to wp-admin/admin-ajax.php would not be possible given this configuration. This ie mentioned at: codex.wordpress.org/Hardening_WordPress#Securing_wp-admin |
|
Mar 9 |
comment |
Side effects of disallowing *.php requests in production environment? Grabbing the feed from another WordPress site leaves 2 open and potentially insecure instances of WordPress on the internet. That's not an answer. And no, posting and comments do not work on this published WordPress instance. This is a feature not a bug, and questioning this aspect of the question means you are not understanding the basis of my question so can't help me. I appreciate you chiming in, but it's not helpful. |
