adrian

You have a good point about the head and foot inc files. It looks like Ryan used the text from the default PW profile which does use that approach. His Foundation profile however actually uses a different approach using _main.php Take a look at: https://github.com/ryancramerdesign/FoundationSiteProfile/blob/master/templates/_main.php Notice that this file contains the entire structure needed for an html page. The content from the PW pages is echoed in various places in this template. For example: <div id="bodycopy" class="large-8 columns" role="content"> <?php echo renderBreadcrumbs($page->parents); echo $body; ?> </div><!--/#bodycopy--> PW lets you work exactly how you want, which can be confusing for some users at first, but you'll come to appreciate it.

Here's a bootstrap 3 profile from phillip: http://modules.processwire.com/modules/process-wire-bootstrap3/

There are two profiles linked to and they are both in the first post of this thread. gebeer's is the one most similar to the Foundation 4 profile created by Ryan (basically exactly the same except that it is running on v5).

This is a replacement profile for PW, rather than a module in the strict sense. Because you this, you must replace those folders before installing, just like it says in the Readme. Good luck.

Bootstrap: http://modules.processwire.com/modules/bootstrap-admin-theme/ https://github.com/jsanglier/Bootwire-Starter-Profile Zurb Foundation: http://processwire.com/talk/topic/5293-zurb-foundation-5-profiles/

Sometimes you gotta do what you gotta do

Well I am not sure I understand - the stuff inside the foreach ($related_id as $key => $val) { will only get displayed if the $related_id array has entries in it so perhaps you need to figure out why there are page ids in that array in the first place if there are no related pages. EDIT: I had some code here that I thought made sense, but then realized it didn't

Also, even though the client is "always right", the reality is that they're actually not always right Unfortunately given them the ability to style fonts in an RTE field is usually a recipe for ending up with a site that looks like it's from the 90's. Sometimes you just have to be confident and tell them No!

Agreed horst - we need to make GD the best it can be. I do like the idea of a drop-in IM replacement though. There are so many settings that developers could tweak with IM. One thing that should be tried straight off is using: adaptiveResizeImage instead of ResizeImage, which is what I used in the module to start with. Anyway, as I said, no time right now, but perhaps if enough people are keen and think the benefits are worth the effort, perhaps we could collaborate on this?

I am not sure on the whole GD vs Imagemagick quality issue. I know years ago IM was ahead, but not sure if that is still the case. From reading around it sounds like they each have their strengths and weaknesses. That said I have always used IM until I started using PW. For the sake of experimenting, I quickly threw this module together as a way to test IM within PW. It replaces the resize method, so it will work from the admin and also template calls like: $image->size(400,0) It doesn't do anything more than the resizing at the moment - it currently ignores all quality settings, cropping etc. I doesn't try to do any sharpening either, but it's a starting point that we can play with. I need to get back to real work, but thought one of you guys might be keen to play around with and tweak settings and see what you can come up with. Obviously you need imagemagick on your server and also the iMagick extension. ImagickResizer.module

Why not just change "modified" to "created"?

If I understand correctly, would counting related_id work? if(count($related_id)>0){

Put these lines in your htaccess: RewriteCond %{HTTP_HOST} !^sharespost.com$ [NC] RewriteRule ^(.*)$ http://sharespost.com/$1 [L,R=301]

Here is a link to a post that links to several others on creating a custom front-end login: http://processwire.com/talk/topic/5121-frontend-users-validation-processing/?p=49360 Here's a great thread on creating a custom front-end form: http://processwire.com/talk/topic/2089-create-simple-forms-using-api/ PW may lack some inbuilt functionality, but it more than makes up for it in flexibility.

Hi Melissa and welcome to the forums! Not exactly what you are asking for, but this might suffice for your needs: http://processwire.com/talk/topic/5835-lister/

You could always place the script outside the PW templates folder and bootstrap it to processwire so you still have access to PW pages and fields for grabbing the validation messages. http://processwire.com/api/include/

Usually the problem with using a PW page for processing a form is the HTML that is included in that page. You need a way to not have this extra stuff sent when requesting the page. How you do this depends on how you structure your PW pages - are you using head.inc and foot.inc includes, or are you using a main.inc? or are you making using of the before and after includes in config.php? You can make use of $config->ajax to see if the page was called via ajax, but then again, if it's just a form processing page, then you probably don't ever need to display it normally, so probably not relevant here. So, call that process page directly and make sure nothing gets rendered. Also, you mention that there is a redirect - is this coming from the process page to somewhere else? I don't think you want that when processing a form via ajax. You want the result of the processing to come back to the page on success. You can echo something back if you want. Here's a pretty decent tutorial: http://code.tutsplus.com/tutorials/submit-a-form-without-page-refresh-using-jquery--net-59

What you have done echoing the url like that in the JS is fine, although you are missing the semi-colon at the end. Look at the page source code to confirm that the final jquery snippet looks as you expect.

Your simplest option might be to use an iframe in the modal - that way when the form submits, it is the content in the iframe that will reload, instead of the whole page. Note that not all modal JS scripts support iframe, but lots do. If you want to go ajax, just google: jquery ajax form submission Good luck.

When you say you have a tmp directory at the root, do you mean the root of your site, or the root of your server? It needs to be the latter. Otherwise, have you tried following those instructions? Create this folder: /site/assets/uploads/ and set its permissions appropriately. Then in your config.php file, enter this: $config->uploadTmpDir = dirname(__FILE__) . '/assets/uploads/'; That should work - let us know how you go. PS alternatively, you could point that config directive to the /tmp directory if it is at the root of your site.

I think the issue is just your single quotes - it is looking for "$answer_text" as a string, rather than "Yes". EDIT: Have a good read through some of these links to get a better understanding of the differences between single and double quotes: https://www.google.com/search?q=php+single+vs+double+quotes

I would suggest that you should store it in this format : 2014-03-19 17:20:10 which is the standard datetime format in mysql. PW does all its conversions from this and you can easily do the same with PHP's date function. Keep in mind that you need to convert from this to unixtime using strtotime before using php date. So, you can convert from RFC3339 to store in PW like this: $pw_date_format = date('Y-m-d H:i:s', strtotime("2014-03-27T17:00:00.000+01:00")); and then take that and add 30 minutes and convert to RFC3339 $RFC3339 = date("Y-m-d\TH:i:sP", strtotime('+30 minutes', $pw_date_format)); You could also make use of PHP's DateTime class: http://www.php.net/manual/en/class.datetime.php

Another pretty major update! There is now an "Edit Imported Content" option during the import process that lets you determine exactly which fields and pages (from the JSON) get imported. This should come in especially handy when importing the one of the Shared JSON packages. I have added a new one that is a good test for this, called "person" (maybe needs a more detailed name), that creates a person template with a complete range of contact/address fields. So, on import you can easily choose only the fields you want from the package. I think this should be really handy for distributing standard templates, but with easy customization for each use case.

If you google that error there are a few possible php.ini settings that might help. Certainly not an issue specific to PW. If you're still having trouble after trying some of the google advice, then this is a question for your host.

Macrura is correct - PW needs mod rewrite. Don't give up so easily on the 500 error - there are lots of possible causes of this and lots of easy fixes - you just need to figure out which one is the issue with your particular hosting environment. If you have tried all the rewrite base options, including matching it to the path of your site on the server, then you might next try: #SetEnv HTTP_MOD_REWRITE On http://processwire.com/talk/topic/1962-cant-reach-admin-page/?p=49524 Or this: http://processwire.com/talk/topic/2439-htaccess-issue/?p=39674 If that doesn't work, take a look through these search results: https://www.google.com/search?q=site%3Aprocesswire.com+500+error&oq=site I am sure we can help you figure it out.