ryan

Now that you mention it, I think that I did have a similar experience a while back. My first exposure to coding was also in BASIC, I think back on old Apple ][e computers. Actually it seemed like we used some language called LOGO back in 2nd grade, where the whole purpose is to make a turtle move around the screen, but can't remember exactly. Even BASIC has come a long way since then (with VB). To me the "GOTO 115" type statements also seem reminiscent of Assembler or COBOL.

Making a module derived from the InputfieldTextarea is probably the best bet. Once you've got it in place, you should see any of your textarea fields let you select it as an option (in the same place where it lets you select between Textarea and TinyMCE). What might be ideal is this: http://markitup.jaysalvat.com/examples/textile/

Ironically, odds are it's due to a broken regular expression in IPB's code.

I was able to reproduce this in a repeater and tracked down a problem (and think I fixed it). Thanks for finding it. This problem would also affect any pages with images that didn't have a template file. Do you want to try the latest dev branch. Or if you are already up to date minus the latest commit, you can replace just /wire/modules/Process/ProcessPageView.module https://github.com/ryancramerdesign/ProcessWire/commit/e000252a264f35deccb081e995a40df451f82952 https://raw.github.com/ryancramerdesign/ProcessWire/e000252a264f35deccb081e995a40df451f82952/wire/modules/Process/ProcessPageView.module

I attempted to duplicate the issue here a few times, but the only way I could duplicate it was (as Arjen mentioned) by enabling the cache for the template that the comments field appeared on. Though I don't think this is the issue in your case, because you still received an email, which would not happen of cache were the problem. Slightly off-topic: For those that want to use comments fields on cached pages, you can still do so. Edit your template that the comments field appears on (Setup > Templates > [some template]). Then click the "cache" tab. For "Comment disabling GET vars" enter "comment_success". For "Comment disabling POST vars" enter "text". Save. Now your cached pages will still work with the comments field. I'll have to find a way for this to happen automatically behind the scenes... but until then, this is the best route to using comments fields on cached pages. Back on-topic: Marc--do you see any related errors in your /site/assets/logs/errors.txt? Can you try going to your comments field and just hit "save"? (maybe there's some setting that needs to be refreshed). If that doesn't do it, try enabling the "Redirect after comment post" checkbox, which is something that I recommend for everyone now. Let me know if you see any change in behavior?

Marc, when you go to your comments settings screen (Setup > Fields > comments > details), what boxes are checked? Feel free to post a screenshot if it's easier.

Atomic Grouping http://www.regular-expressions.info/atomic.html Negative Lookbehind (and family) http://www.regular-expressions.info

Sounds good guys, I'm going to go with a slight modification to Joss's suggestion: Will also append a blowfish hash of that Oxford word, combined with a random salt (to avoid the obvious URL dictionary attacks). In all seriousness, I do think it's a fine practice to have a unique URL for your admin. But the admin is password protected, so it's not really necessary to change your admin URL unless you or your clients are going to be practicing bad password habits. Still, every little bit of security is always good, especially ones that are so easy to add.

That's correct. That language is going to need to be set before the [cached] page renders, since you are selecting a language based on subdomain. Best way to accomplish this might be with a module. I think this below would do it. You'd have to update the last function there to reflect your actual domains an language names. /site/modules/LanguageSubdomain.module class LanguageSubdomain extends WireData { public static function getModuleInfo() { return array('autoload' => true); } public function init() { $this->addHookBefore('Page::render', $this, 'hookRender'); } public function hookRender(HookEvent $event) { $host = $this->config->httpHost; if($this->config->httpHost == 'es.domain.com') $lang = 'es'; else if($this->config->httpHost == 'fr.domain.com') $lang = 'fr'; else $lang = 'en'; $this->user->language = $this->languages->get($lang); } }

This is correct, the pattern is validated at server side too, so the HTML5 attribute is just a "nice to have". Though the fact that it's there provided good motivation for adding pattern support to the text field. Previously I thought regular expressions were too cryptic and code-oriented to expect from most users. But hey, if HTML5 is suggesting it and most browsers are implementing it, then we absolutely should. Personally I love regular expressions, but don't know many web developers that know how to use them. But it looks like that's changing, and sites like that html5pattern.com are great resources too.

I'm actually thinking I might just making it an input in the installer. "What do you want your admin URL to be?" or something like that.

Happy birthday Joss. You'd want to render each individual page $items = $pages->get('/home/blocks/footer-blocks/')->children('start=0, limit=3'); foreach($items as $item) { echo $item->render(); } I added that "start=0" into the selector, just in case you are using pagination somewhere on the page. Otherwise, that isn't necessary.

Do you have a URL for the specific plan this is at Rackspace? I'd like to do a little more research just to see what the issue might be. I might be able to tell something from phpinfo or even their sales page. Or if this is a VPS or something where you can easily setup an account, I'll be happy to login and troubleshoot it.

This question has actually come up many times. You guys will be glad to know I've just pushed some updates to the installer for 2.3 that tells you how to change the admin URL: https://github.com/ryancramerdesign/ProcessWire/blob/dev/install.php#L527

This is actually fixed in the dev branch. You could switch to the dev branch, or you could copy the relevant file out of it (/wire/modules/PageRender.module) and replace the one you have. Here is the commit highlighting the changes: https://github.com/ryancramerdesign/ProcessWire/commit/6c6f27ea0f0df4653ac241f5c8b54d44e1c36494

The problem with having multiple sites pulling and/or manipulating from the same database is that the two sites become dependent upon one another. If something needs to change with the data source, then both sites need to change. If one site becomes compromised, both sites are compromised. When two sites need to talk to each other, regardless of platform, the best practice is to use JSON or XML web services. For the example you mentioned, and in the context of ProcessWire, I would use RSS feeds. Generate a feed of the data you want to share using the RSS Feed Generator module. Then output it on another site using the RSS Feed Loader module. Now you have two sites easily sharing data in a bulletproof manner. For more complex needs, you might also want to check out the Pages Web Service module.

If you want to access another MySQL connection, you have any of the native PHP options (mysqli, PDO) available at your disposal. You could also use ProcessWire's Database class (derived from mysqli) to start another connection. Lastly, you could include some other library like to use ActiveRecord from Code Igniter, for example. Personally, I would just keep it simple and use Database, mysqli or PDO. But I would not use mysql_connect, because the old mysql driver in PHP is deprecated... you can use it, but your code might break in some future version of PHP. If you want to use PW's Database class, here's an example of how you'd do it: $mydb = new Database('localhost', 'user', 'pass', 'db_name'); $result = $mydb->query("SELECT * FROM some_table"); while($row = $result->fetch_assoc()) { print_r($row); } See PHP's mysqli functions, as the Database class essentially is identical to mysqli with some extra PW-specific stuff thrown in that won't matter if you are interacting with a non-PW database. To use native mysqli, you'd just replace "new Database(...)" with "new mysqli(...)".

In our case they aren't read-only sites in terms of content. I'm mirroring their content to a staging server so that I'm working from a reasonably new copy, but I don't ever push that content back to the site. They have staff making edits to the sites all day long and they decide when/where content goes. But the staff focuses just on content, and they don't even see the Setup menu. I run the staging server for everything but the actual content. I'm pushing mostly changes to template files and modules, and [less often, when needed] templates and fields. When another developer is involved, they stage to my server too, but I'm the one that does the migration to live (good to have a gatekeeper I figure). There are occasionally times when we do need to push content additions, like adding a few hundred pages at once or something. But I use PW API code to do this, and it becomes a script that gets played first on staging, then on live. Things like database IDs aren't a factor since it is scripted rather than imported data. The same approach could be taken with those schema changes (templates, fields) but in my case they don't represent much of the changes, so it's usually quicker to just issue those changes manually. But my case may not be the norm. And if the core (or a module) did keep track of this for me, I'd probably use it.

Yes, I've been meaning to add it but neglected to put it on my list. I've just added it, so will plan this as a 2.3 addition.

Unless I misunderstand, i think the answer is actually the module that this thread is about. Option 1 is for multiple databases that don't share data. Option 2 (this module) is the one you'd want with multiple sites sharing data.

not yet I don't think, but that's a good idea!

Pattern support is now in place for text fields (dev branch). The pattern applies both client side (HTML5 pattern attribute) and server side, for the validation. I looked through all of those patterns are html5pattern.com and couldn't find any that weren't PCRE compatible. So if it's not 100% compatible, I sure can't tell the difference. My guess is that HTML5 patterns are compatible with PCRE, but some of the more advanced PCRE stuff (maybe atomic grouping or negative lookbehind?) might not be compatible with HTML5.

Those are pretty awesome tricks! But do these things really save time, or do they just save space?

if(count($page->gallery_image)) didn't work, I'm guessing gallery_image is not a repeater field? Try this to see what you get: echo "<pre>gallery_image is: "; if(is_object($page->gallery_image)) { echo "object of type " . get_class($page->gallery_image); if(WireArray::iterable($page->gallery_image)) { echo " with " . count($page->gallery_image) . " items"; } } else { var_dump($page->gallery_image); } echo "</pre>";

The methods Soma mentioned are great best practices. Admittedly I'm not always that complete, especially on smaller sites where there's not much benefit [for me at least] in pursuing objects and modules. In these cases, I'll just make a /site/templates/functions.inc file that includes procedural functions for everything I need, like renderNewsItems($items); renderSubnav($items); etc. In some cases I might create a couple of different include files that have groups of related functions that I can selectively include where needed. Then the template files that need any of these functions just includes functions.inc (or other include file) at the top. This is sometimes the path of least resistance. /site/templates/news-index.php <?php include_once("./functions.inc"); $page->body .= renderNewsItems($page->children); include("./main.inc");