adrian

The first thing I notice is the spaces and mixed case in the filenames. This is a bad idea for lots of reasons which is why if you uploaded the docs via a Files field in PW it would have converted them for you. I think what is causing the 404 is PW's htaccess rewrites. It sees: http://ahaa.inthooz.me/assets/form-downloads/ and goes looking for a page with that path. You could potentially move form-downloads into: http://ahaa.inthooz.me/site/assets/form-downloads/ and things should work just fine. But, why not upload them to PW and have files that are part of the system? EDIT: having them all in a files field in PW means you could use this code to provide download links to all and it would automatically work for all new files as they are added: echo "<ul>"; foreach($page->files as $file){ echo "For the {$file->description} form, <a href='{$file->url}'>click here!</a>"; } echo "</ul>"; Although personally I hate "click here" links, but I went with how you had things structured already

Also, a little more? info here: http://processwire.com/api/variables/sanitizer/

Macrura, If you look at the DB table for the PageTable field you'll see how the data column lists the page ids that are included as items in the PageTable. I think you should just have to add rows for each of the pages you want included for editing in the page table. I was actually thinking this morning about this - currently it is possible for someone to add a new child page manually, but these won't appear in the PageTable field for editing. I wonder if there needs to be a way to prevent this as it could get confusing. Another issue for PageTable fields in my mind - if you use the default page as the parent for storing the entry child pages, but you also have regular child pages mixed in, it may become quite confusing for editors. I guess this comes down to the dev being careful about choosing a different parent in cases where there might be confusion. Did that make sense?

The fix was after the 2.4 release so you'll need to either update to dev, or you could make these changes to 2.4: https://github.com/ryancramerdesign/ProcessWire/commit/e2f701fc3db0810395a904a508e862a2da615cc2 Lots of us are running the dev version on production sites, but it's up to you - occasionally issues pop up, but it's not very often.

I am pretty sure this has already been fixed in the dev version. Here is the initial report of the problem: https://processwire.com/talk/topic/5605-delete-image-from-grid-view-not-possible/ And here is the Github issue: https://github.com/ryancramerdesign/ProcessWire/issues/363 It was fixed in early March.

Well, you could use: http://modules.processwire.com/modules/fieldtype-map-marker/ but I wonder if the Google static maps API might be better if it is in the footer of every page: https://developers.google.com/maps/documentation/staticmaps/?csw=1 There is a limit of 25000 hits per day, so if you'll be inside that, it's a decent option. The only catch with the static option is providing a GUI way for users to add markers. There are other options out there too, but let us know if you think either of those will work.

Hi qlex and welcome to PW - hopefully you'll stick around after this client request Here are the instructions for using the RSS module: http://modules.processwire.com/modules/markup-rss/ Also, you may want to consider this enhanced version of the RSS module: http://modules.processwire.com/modules/markup-rssenhanced/ Let us know if you need any specific help getting things to work.

Regarding your enddate not saving, there are a couple of things going on. InputfieldCourses.module: Change: $course->dateend = $dateend; to: $course->dateend = $input->{"{$name}_dateend"}[$cnt]; Course.php Change: } else if($key == 'date') { to: } else if($key == 'date' || $key == 'dateend') { That will get your dateend field saving on creation. However, the one thing I just noticed is that you can't make any changes to the course once it is saved. I haven't investigated this yet, but did you notice that also? EDIT: Also those checkboxes are going to have issues - you need to a checked="checked" in each input based on whether there is a 1 in the database or not, but you'll also need to take care of assigning that "1". Now for why changes are not saving - I am still not sure exactly why and have run out of time, but a quick and dirty fix is to comment out this line in InputfieldCourse.module: if("$courses" != "$this->value" || $numDeleted) { I don't really know why $courses and $this->value are not being set appropriately, but they are both set to "Course" which obviously isn't much use. Hope that all helps a bit.

Don't worry about overcomplicating - I think everyone still does that at times when learning something new. There are so many ways of doing something and it often takes time and reflection to realize the simplest way, especially when the goals of your site or app change as you go along. That code I gave would produce a multi-dimensional array something like this. So for each track id, you'll have available both the title and the lyrics as separate key/value pairs that you can access. Array ( [156] => Array ( [title] => Song Title [lyrics] => This is the way we code, the way we code, the way we code ) )

I don't see how it is possible in grid view, so your editors need to know to switch to list view to enter descriptions using the button at the top right of the images field.

All of the standard PW variables must be converted to wire("variable") when you want to use them inside a function. I think you've probably already had variable scope mentioned to you, but you should read this (http://www.php.net/manual/en/language.variables.scope.php) at some point so you understand why the PW variables can't be used inside a function. I don't understand what you mean about get() or find()

If you can view your site's homepage but get that error on all others, then it is most likely the RewriteBase setting in the .htaccess file. Try uncommenting the first option to start with. If your site is in a subfolder, then create a new option like the second example provided and try that. Should be pretty easy to sort out.

This is one of those things that gets everyone every now and then. One way to to avoid it is to define them in opposite order, so if you accidentally forget the second = you will get an error, instead of setting the variable to the value Like this: if ("typical-day" = $page->template) will throw a parse error, but with "==" it will work as expected. As for whether you should change templates at run-time - there should be no problems doing this and it can be quite powerful.

What you want is: if($page->template == 'album'){ The $page variable is the current page in PW, so this returns the template for this page.

When you're building your array, make it multidimensional. Something like this should do the trick: $lyricsArray[$track->id]['title'] = $track->title; $lyricsArray[$track->id]['lyrics'] = $track->lyrics; Then when you a are foreach'ing it, you can: foreach ($lyricsArray as $track) { $lyricModal .= $track['title']; $lyricModal .= $track['lyrics']; } But then I am also wondering why you are converting the $track object, which already has title and lyrics, into an associative array. Is it just for the lyrics empty check? If so, then you can do that by foreaching the albumTracks object again: foreach ($albumTracks as $track) { if ($track->lyrics != null) { $lyricModal = '<div id="songID_' . $track->id .'" class="reveal-modal small" data-reveal>'; $lyricModal = '<h2>' . $track->title . '</h2>'; $lyricModal .= $track->lyrics; $lyricModal .= '<a class="close-reveal-modal">×</a>'; $lyricModal .= '</div>'; echo $lyricModal; } } Does that do what you want, or am I missing something

Hi joer80 and welcome to PW! You can get a count and list of all queries on a page like this: $queries = $database->getQueryLog(); echo '<p>Number queries: ' . count($queries) . '</p>'; foreach($queries as $query){ echo '<p>'.$query.'</p>'; } Just put that somewhere in your home template. I have to run out the door, but someone should chime in with how to use your own SQL easily. There are posts about it here. Google search is much more effective than the forum's built in one. Good luck!

Yeah, I thought that was probably the case (not uploading, but creating on the server), but thought I'd share, just in case. This sounds like a great addition btw - I have been a little slack on the retina thing myself at times, so it would be awesome to have a built-in solution. Thanks for working on this!

In case you guys haven't seen it, this might be relevant: https://processwire.com/talk/topic/4544-image-field-changes-file-name/

Kongondo, Regarding blog_date field. I get the feeling it is designed to be the date/time that the blog post is published, but from what I can see it gets set when the post is first created and doesn't automatically change after that. I might be misunderstanding your use of the field, but I would like to see it change automatically when the post is published and not change after that - maybe even disable user editing of it? I know we often draft up several posts at a time and publish them later. I don't think we should have to manually adjust this field when publishing the post. Another thought for you - have you considered integrating this module: http://modules.processwire.com/modules/schedule-pages/ or the functionality from it into the blog posts tab? This would make WP users feel at home. Thanks for considering.

Great first post ukyo - welcome to PW and thanks for the contribution!

You can get the latest dev from here: https://github.com/ryancramerdesign/ProcessWire/archive/dev.zip This version will become 2.5 fairly soon.

I manage my own servers and I have certainly enjoyed the learning and freedom that goes along with that. It is great to be able to compile the latest version of something yourself on the day it is released and to be able to mix and match various versions of software as needed. It can definitely have its frustrations though when dependancies are not playing nicely. Things are generally simpler if you use pre-compile packages and a package manager like aptitude or yum. I think @cstevensjr's comments about security might be your biggest issue - there is a lot to learn on that front and it can bite hard if it's not done right. Of course I bet you could probably do better than a lot of the managed options out there on your first time anyway. When I do deal with hosted sites, I haven't had great experiences, usually because the client has been with a host for a long time and doesn't want to change. There are some horrible operators out there I need to start making sure I get to choose the provider in future!

I posted about this on kongondo's blog module thread, but wanted to note it here too I just tested Nico's new version, tweaked the field and template names to match those used by K's Blog module, imported my WP blog xml and it worked brilliantly. Great work Nico!

kongondo - really fantastic - you have put a huge amount of thought and work into this. I just tested an import from WP using the latest version of Nico's MigratorWordpress. I just edited the config settings in his module to match your template and field names and bingo, a perfect import!

Yeah, I am sure you are distraught Now we just need someone with some Drupal skills to write a MigratorDrupal plugin. Anyone?