Jump to content

Ben

Members
  • Posts

    39
  • Joined

  • Last visited

Everything posted by Ben

  1. I'm not sure I fully understand what you are trying to do, but character encoding can be a hornets nest, especially if you are destructively transforming text. Assuming the characters are going into the database correctly, one non-destructive way would be to use a TextFormatter module to apply output formatting - something like this: class TextformatterReplaceChars extends Textformatter { public static function getModuleInfo() { return array( 'title' => 'Replace Characters TextFormatter', 'version' => 100, 'singular' => true, 'autoload' => true, ); } public function format(&$str) { $str = strtr($str, "äåö", "aao"); } } Edit: After re-reading, I think you may mean url name/slugs? Sorry if I missed the boat with my answer.
  2. Ryan, this is exactly what I was looking for. Thank you.
  3. Thanks Ryan, reading your response I realized that I could modularize exceptions and raise that at will, which is sufficient. I still wouldn't mind wiring a 500 error through a template, but I understand the descision to halt full stop.
  4. Just a thought. It would be nice to have the same output contol of the 404 Not Found error extended to the 500 ISE, 403 Forbidden, 503 Service Unavailable and other commonly used http status responses.
  5. I'm not terribly informed about the ins and outs, but judging from the source it doesn't appear to be currently supported. The easiest solution would be to buy a month of cheap hosting for evaluation or up the plan at the current host. Of course, that isn't anything you didn't already know.. It might be hackable through the __call method of the DatabaseQuery class (regex replace of all known database tables), but that would break the installer, generally be unpredictable, and likely end in catastrophic failure. Edit: the installer definitely uses fixed table names (install.sql). Changing DatabaseQuery would not prevent the installer from overwriting your existing "pages" table. So what was a bad idea in the first place (hacking __call), is much worse than initially suspected.
  6. My suspicions were correct, there's no need to do anything crazy. The API handles it fine - $page->images->add() was what I was looking for. Part of the frustration was that I mislabeled the switch case, it should have been 'FieldtypeImage' as opposed to 'ImageFieldtype'. Now if I could only control the name of the phpRANDOM.tmp filename being created, but that's a different matter. For anyone looking for a solution, here's an updated snippet: foreach($page->template->fields as $template_field){ $field_name = $template_field->name; $field_class = $template_field->type->className; $update_value = $this->input->post($field_name); switch($field_class){ case 'TitleFieldtype': case 'TextareaFieldtype': $page->{$field_name} = $update_value; break; case 'FieldtypeImage': if (array_key_exists($field_name,$_FILES)){ $img_path = $_FILES[$field_name]['tmp_name']; $img_name = $_FILES[$field_name]['name']; // $_FILES array singular vs. multiple // normalize by converting single to array prior to looping. // http://php.net/manual/en/reserved.variables.files.php if (!(is_array($img_path))){ $img_path = array($img_path); $img_name = array($img_name); } for($i=0; $i < count($img_path); $i++){ $page->images->add($img_path[$i]); // TODO, change image name from phpXYZ.tmp } } break; ... } ... }
  7. Coming from another angle, maybe you could include a replacement json_encode in the application? Just make sure it gets loaded in before it is called. Here are a couple alternatives for older PHP: http://snippets.dzone.com/posts/show/7487 http://www.boutell.com/scripts/jsonwrapper.html
  8. I've been working on an automating an import of some pages. For all intents and purposes, it's basically a form submission to a module process that creates/updates a page of a certain template. For the literal minded, I'm importing an existing news archive (headline, story, byline, image) by scripting the form submission. So far, everything has worked great, and I can update the text/textarea fields without any issues, but I'm not able to figure out how to attach an image in the $_FILES superglobal to the $page object. I suspect my thinking on how to do this is backwards, and there may be an API method that handles some of the lifting - but I don't mind getting my hands dirty either if I need to code it closer to the metal. I've starting to look at the FieldtypeImage source and the inheritance thereof, but I'm starting to find myself out in the weeds. Does anyone know of a way to affix an uploaded image (outside of the page admin) to a $page object? The input handling of the submission currently looks a little like this: foreach($page->template->fields as $template_field){ $field_name = $template_field->name; $field_class = $template_field->type->className; $update_value = $this->input->post($field_name); switch($field_class){ case 'TitleFieldtype': case 'TextareaFieldtype': $page->{$field_name} = $update_value; break; case 'ImageFieldtype': // <----- the confounder // not sure what to do here if the field // if name is represented in $_FILES break; ... } ... } EDIT: Simplified code block.
  9. Sorry for the delay (vacation). The distro was an Amazon Linux AMI on EC2, which from my understanding is a forked version of CentOS.
  10. Netcarver, genius. Ok, so using LAMP with the prefork mpm - I'm seeing rock solid stability. First with 1000 requests using 10 workers (ab -n 1000 -c 10), then with a barrage of 120 concurrent requests (ab -n 120 -c 120). I can only guess that there's some php interaction with the worker mpm that is at fault. Searching about, I'm seeing fuzzy references to php limitations using the worker mpm, but no definitive list of off-limit extensions or programming patterns. I might dig a little deeper, but seeing as LAMP deployment is an option it's no showstopper.. Thanks again.
  11. Netcarver, I think you are on to something with testing on LAMP - I'll setup another test today with muti-process apache to try and rule out PHP/extension thread-saftey issues and report back. Ryan, I'll use the base install theme for future testing, always a good idea to keep it as simple as possible. Oh, and thanks for all the great work - though I've only been working with it for the past 3 days, ProcessWire has the best feel out of all the CMS options I've tried. Coming from a Django background, I appreciate the focus on framework over extraneous features. It strikes a really good balance. Thanks guys!
  12. It's the same, only using httpd.exe, "httpd -V" It is multi-threaded, I think. Here's the info: Server version: Apache/2.2.22 (Win32) Server built: Mar 19 2012 12:20:03 Server's Module Magic Number: 20051115:30 Server loaded: APR 1.4.6, APR-Util 1.4.1 Compiled using: APR 1.4.6, APR-Util 1.4.1 Architecture: 32-bit Server MPM: WinNT threaded: yes (fixed thread count) forked: no Server compiled with.... -D APACHE_MPM_DIR="server/mpm/winnt" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses disabled) -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/apache" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error.log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf"
  13. Thanks Netcarver. With one thread it runs the course without fail. It's definitely seems to be related to concurrency. I found a mysqli bug on php.net that I almost thought was it, but after updating to php trunk it's still there. I'll let you know if I figure anything else out.
  14. I'm not sure there's anything that can be done as the segfault is likely a PHP bug - but there are a handful of libraries that can leak memory (e.g. Simple HTML DOM Parser) so I figured it wouldn't hurt to ask. The backstory is this, basically I'm in the process of selecting a CMS - looking at WP, EE and ProcessWire. ProcessWire seems to be the brightest bulb of the lot, but I'm getting a nasty error when using ApacheBench to load test. Neither EE or WP cause the fault under the same load, so I don't beleive it's a bad extension and/or configuration. The issue initially showed up with a development site, but I've since set up a vanilla install of the skyscraper demo to reduce the potential of having introduced the problem with my own code. The system is WAMP: Apache 2.2.22, PHP 5.4.0 (also tried 5.2 and 5.3 with same outcome). The load test is an Apache Bench where 127.0.0.9 is the skyscraper site, with 10 threads and 1000 total requests: C:\>ab -n 1000 -c 10 http://127.0.0.9/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 127.0.0.9 (be patient) apr_socket_recv: An existing connection was forcibly closed by the remote host. (730054) Total of 3 requests completed There is no error in the apache logs, but in windows event viewer the cause is clear: Faulting application name: httpd.exe, version: 2.2.22.0, time stamp: 0x4f6715c9 Faulting module name: php5ts.dll, version: 5.4.0.0, time stamp: 0x4f4e7f05 Exception code: 0xc0000005 Fault offset: 0x0004c633 Faulting process id: 0xf98 Faulting application start time: 0x01cd084ebe38d790 Faulting application path: C:\Program Files (x86)\Apache Software Foundation\Apache2.2\bin\httpd.exe Faulting module path: C:\php\php5ts.dll Report Id: 0a4e4bf8-7442-11e1-95ce-14feb5ecd87c Outwardly, this returns a blank (white screen) - I was able to mash F5 refresh enough times to get it to show up in the browser. Without running ab with concurrent threads, everything is fine. Setup is pretty much a stock install (php + gd2, mysqli, mbstring), and I've not encounted stability issues prior. Apache doesn't appear to be the issue because the fault can occur in less than 20 requests, though usually many more are handled. If you're still reading this, thanks for sticking with... My question. If you were to divide and conquer in order to discover what is behind it, how would you go about doing so? Thanks.
×
×
  • Create New...