ryan

Wasn't Foundation v2 also responsive? I've not checked out 320andup yet, but am going to take a closer look today. And this gridpak generator looks pretty awesome. great links. I think mobile-first sounds like a great slogan but not a great strategy. It's easy to identify sites that have taken that strategy because the non-mobile version of the site often seems like… an enlarged mobile site. I've not done a lot of mobile stuff yet, but with what I've done, I prefer to focus on both at the same time. Otherwise it seems like sacrifices are being made to one or the other. The full-size design is still what I ultimately have to sell to the clients. There's fewer variables on the mobile side in terms of design and that part [so far] seems a lot simpler to account for (and easier to get approved too). So I guess I think the picture should be bigger than just mobile first. Sorry, maybe I'm a bit off topic, but just remembering an overabundance of mobile first hype at an AEA event last year.

That's a pretty nice code editor there, thanks for the link. Will have to take a closer look. For the most part though, ProcessWire assumes you have your own tools for editing things like your templates and CSS files, and is trying to stay out of your way in that regard. There are also some security issues with enabling direct editing of PHP files on the server. Though I still think this is a good idea for a non-core module, to provide editing capability of template files for those that want it.

It should be that second argument to RCDMap.addMarker, where you could specify whatever URL (or anchor) you want: RCDMap.addMarker('some title', '/some/url/', lat, lng); RCDMap.addMarker('some title', '#some_anchor', lat, lng);

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.