Leaderboard

@EvanFreyer, open your .htaccess file and look for this line: # OPTIONAL: Send URLs with non name-format characters to 404 page This is the first step at enabling non-ascii URLs, though I'm not entirely sure if it's the only one you need to change.

Maybe how we do it in the Blog Module can be of help. Have a look at the Hooks here.

Because I think that this should be a feature of the Shedule Pages module, I forked the module, added an option (so that this feature can be turned on optionally) and made a pull request: https://github.com/formmailer/SchedulePages/pull/8

Works like a charm. I made minimal modifications to make it work without the rest of the Blog Module: https://github.com/MichaelvanLaar/PW-AutofillPublishFromDate My version of the module simply does its job for every page which has a publish_from field which is installed with the Schedule Pages module.

I know this may be more of a "Pro" feature right now, but PageTables could really sport the AJAX editing option like ListerPro, maybe even just for enabled fields. In some cases the PageTable might be quite narrow where only a small select option should be editable and a field with a more spacious inputfield should not be editable.

1. is easy: If there's no corresponding template.php for a template, than nobody can see it from outside. Furthermore, the only thing a search engine can crawl is the html you're outputting in your templates, so those children could even have template.php files, but not output markup and e.g. redirect to 404 on direct access. 2. If SEO is important I'd go with a one-page-per-asset approach, so you've all the flexibility to show and use those assets in the way you want. 3. Drafts is still an issue, that I doubt will be fully solved until a core solution is introduced.

Since a Repeater item is a kind of page the numbers are the id's of the extries of the repeater... so have a closer look at: https://processwire.com/api/fieldtypes/repeaters/ like in the example you have to call the fields like: foreach ($page->info_tabs as $tab){ echo "<div>"; echo $tab->title; //or if you have a special text field echo $tab->myFieldName; echo "</div>"; } regards mr-fan

I am going to chime in and say that isn't really correct There are lots of acceptable ways to do something, but even as brilliantly thought out and architected as PW is, it doesn't prevent you from writing template code that results in slow/inefficient queries and also potentially dangerous holes that users could exploit. Keep in mind that there isn't any CMS out there that can prevent you from making these mistakes. PW makes it easy to do it the RIGHT WAY, but you still have to think things through, follow best practices, and if in doubt ask someone more experienced if you are doing it right, or at least make sure you are not doing it wrong!

You could use the config options for page secure files... $config->pagefileSecure = true; $config->pagefileSecurePathPrefix = '-'; and make unpublished pages and their files will not be accessible via url. So you could create child pages under the users page with a file field, and leave those pages unpublished. The assets directory will be prefixed with "-" which is restricted by htaccess. But then you can use a passthru script to send the file to the user if certain requirements are given using wireSendFile(); So for example construct the download link to the file like this on a page the user can see. <a href="/download.php?user=1007&file=filename.pdf">Download file</a> and in download.php with something like this for the passthru and user check // bootstrap PW include("./index.php"); // make sure user is logged in if(wire("user")->isLoggedin()){ $file = $_GET['file']; $userid = $_GET['user']; $userpage = wire("pages")->get(wire("user")->id); if($userpage->id != $userid) die("no access"); // make sure it's the user if($filepage = $userpage->child("include=all")){ // since page is unpublished we add include all // get the file from the page $filename = $filepage->images->get($file)->filename; if(!$filename) die("download not found"); // send file to browser wireSendFile($filename, array('exit' => true)); } else { die("no user page found"); } } else { wire("session")->redirect("/somepage/"); }

: Guys, this is sooooo cool !!! Having seen the modifications done to the bike, and checked with google, this is not fake, but for real !! Discharge from coding for 4 minutes and enjoy watching this => It actually starts at 1:12 .

We've been using PW since 2.3 for a lot of our websites and have found it to be suitable in almost any scenario it just seems there is nothing it cant handle. The clients love it because its easy to use and very intuitive. The Pro Forms module has also made our lives just a little easier when it comes to creating front end forms. Every now and then we come across a problem and we've always found a way to make it work with PW. With that said, I was hoping to get an idea from other developers what their approach is and what might be the best route to choose in terms of best practices in the following scenarios. 1. Repeaters or Pages We know that repeaters are essentially pages living under the admin tree. In a case where there may not be that many repeatable items we want to maybe just allow the client to create sub-pages (children) under a specific page in the back end. We always wondered if this is a good idea since we don't want the visitor, search engine bots, etc to be able to crawl or view those pages directly. Whats the best option here? Unpublished? Hidden? Template without file? Essentially how do we create pages that can be pulled by the api but do not serve any other purpose such as no url, not visible on the front end, etc? 2. Assets We just recently built a site where our client had several hundred in assets varying in type such as webinars (video template), white-papers (direct pdf download), podcasts (direct mp3 download), success stories (regular html template) etc. We created an unpublished page in the root and had 5 published children underneath that page considered as type. SEO value was important to us for all of these assets. How do you guys normally handle these types of assets what is the proper approach in PW. 3. Drafts We've posted this question before and seems its under development but im wondering how do you handle a scenario where you need to preview changes on the home page for example before pushing it live? We tried the ProcessPreview Module but that doesnt seem to work well with our custom classes and functions. Basically our client needs to make changes to a page send a link for approval and only once it is approved apply the changes. For other pages we normally duplicate it add a "v2" at the end and keep it unpublished, send the url, get the approval and then either merge the changes manually or delete the original entirely and rename the v2 to the original name then publish it. This process is tedious and it doesn't work for the home page. I may have been vague in my questioning but i hope you get my general point. Im just looking for some direction and assistance on how to approach these scenarios.

Quickly toggle your checkboxes with extra action buttons via AJAX. The module adds functionality to InputfieldCheckbox so you can toggle the checkbox fields in the extra action buttons intruduced in ProcessWire 2.6.5 via AJAX. Github Page Download Link Requirements This module works only for ProcessWire versions later than 2.6.5. How to Install 1. Copy the files to /site/modules/ProcessQuickToggle/ 2. In your admin, go to Modules > Refresh for new modules. 3. Click the "Install" button next to "Process Quick Toggle". Usage Go to any checkbox field you want to enable quick toggle feature for. Setup > Fields > my_checkbox_field. There in the Input tab you should see an Enable Quick Toggle field. After you check it you will see some fields that you can fill based on your needs. Then save the field. Now there should be an extra button for every page that has this field in the Pages tree. Features Supports template contexts. Supports core FontAwesome icons. Any kind of feedback is appreciated.

Soma's process worked great for our needs! Made a couple of modifications to meet our requirements: we are protecting content based on invoice lookup from Unity3D.com. Once the authorization has been achieved it is stored in a session var. We also created a field in our invoice-protected page template for entering the pageID of the UNpublished page holding the download files. The only thing that needs to be passed to the passthru script at this point is the filename. The Unpublished pageID and the user's authentication status are "passed" to the passthru script via session variables -- keeping auth and page location behind the scenes. The passthru script checks for authentication via the session var and looks up the file on the page using the pageID session var. If the file is not found, we redirect to an unlisted page with information on what the user should do. Thanks a bunch Soma!!!

Following this discussion I forked the module and added a new option: Always use “Publish From Date” field to store publishing timestamp If the new option is set to “Yes”, the publish_from field is automatically filled with the current timestamp in case a page is published manually. This way the publish_from field always contains a page’s publishing date – even if there was no scheduling via the publish_from field. This mimics the publish date field behavior of WordPress and is extremely handy if you use the publish_from field in a blog’s front end template. I made a pull request: https://github.com/formmailer/SchedulePages/pull/8

anything funky makes we work faster, together with PW its light lightning fast

Don't date/time fields have the option to default to the current time/date. That's how I handle it and then manually set it if required.

I'd recommend www.getpostman.com the next time you're trying to test api requests.

Results are in. Used mockaroo to generate a bunch of entries, pumped pages up to over 1100, ran a search... 3.9 seconds! Then I scrapped all the fields I'm searching, left only one, and got 1.9 seconds. Still way too much. With limit=100 on the first block gathering and still keeping the whole process I got it down to 0.35 seconds. That's much more like it. Now I have to figure out how to narrow down results on the first find. Good luck to me

That's just the thing. I have 15 fields to search on and must do it progressively. 4 of those fields are considered primary, and a keyword that's found in one of those sets a narrowing point. From there on, search focuses on these pages and that keyword is excluded from search in other fields. So you search "Cola", and if the engine finds entries with that on the brand name, it will ignore others that have that word on the description. Also, this allows the engine to give alternatives if it can't find all the words. You search "Awesome Nike", it will discover pages with "nike" but none that also have "awesome" in it, and so returns something like "Sorry, no results for the complete query. Showing results for "Awesome Nike". This will be a b**ch to optimise. I'll have a look at https://www.mockaroo.com tonight, to generate my bogus entries.

At the moment Raymond's answer seems to be the only working solution. This is essentially the same thing that @thetuningspoon posted in this issue: https://github.com/ryancramerdesign/ProcessWire/issues/1121, and it's been one of the very few major headaches for me since the beginning. In my opinion when something is set as "required", it should mean "required", not "recommended". The page should not be saved under any circumstances unless all required fields are filled in. From what I can remember, this has been discussed before, and the general idea was something along the lines of "a page with a lot of fields and couple of them required could result in a lot of lost data if it wasn't saved when one of the required fields was left empty". Essentially the page can be saved, but left unpublished, and thus considered as "temporary storage". This, again in my opinion, would be better solved by storing those values not within actual pages, but a) some temporary alternative, b) within browser memory, or c) within session variables. Of course that would be a new concept for ProcessWire, and Ryan might also have other reasons to stick with the current behaviour Just my (relatively unhelpful) two cents. Edit: Just wanted to add that one specific issue with the current system is that once I fill in all fields I can publish the page, but after that I can clear required fields, save the page, and it remains published. This, at the very least, is not what I'd expect.

I do not think the default required checkbox is sufficient for that, since even tho the field becomes a required value, the page will just save. It can be achieved with a simple process autoload module that hooks in to Pages save() method as a before hook. $this->pages->addHookBefore('save', $this, 'yourMethodToCheckTheValue'); Create a method that checks the validity of the value. When the value is invalid you can replace the method you are hooking so that it will not continue and save the page, perhaps throw in a nice error rmessage for the admin to read.

That's why I specifically added the "like the name field" part. Having a field required by this checkbox does not prevent a page/user from being created/saved, which is what I want to happen.

What is of() Baby don't hurt me Don't hurt me no more can't stop singing

I would advice against repeaters. This would definitely become a performance issue in the long run. What @Martijn suggested sounds like a possible solution too, though that would require creating a lot of pages. Depends on how popular your site is, but this sounds like another scalability issue to me, and at the very least it would create unnecessary load on your server. Table field from the (commercial) ProFields module bundle would be a great fit for this task. It creates a database table of its own, which would make sense here. Another option would be a new module that does pretty much the same, though that would be more complicated to set up. Unless there's something I'm completely missing here, I would actually suggest a completely different route. What you're doing here is trying to recreate a subset of what Piwik and Google Analytics already do extremely well. That doesn't make any sense to me at all. Set up Google Analytics and let it handle collecting data. If there's a need to pull the data to your site and display it there (instead of within GA GUI), use Process Google Analytics or query the data via GA API. There are PHP libraries available for doing that, so it's not that much of a hassle really.

I realize that. Even used the Google to run a search on the forums. Seemed like the previous threads were a bit old. I should've just bumped Ben's thread here.

Hi guys, So, here is our latest creation. http://wine-route-georgia.com/ Wine Route Georgia provides exclusive tailored tours throughout Georgia including wine tastings and vinery visits. We were lucky to have a great set of images to work with, so we decided to design the website around them. The strategy was to keep the images in the background with a very slow slideshow, and for this we had make sure that it wouldn't be interrupted while the user navigates the content. Enter AJAX: Obviously the only way to do this is to use AJAX to get the requested content. We wanted the URLs to work normally and used this technique to make sure everything would work flawlessly http://rosspenman.com/pushstate-jquery/ . On PW the work was not different than a normal website with separate pages (including header and footer) since all the work is done with JS. The slideshow is quite complicated because it works differently when in responsive mode. On smaller devices, the slideshow pauses and becomes draggable. On larger devices you can call a grid with all images and select the one you want to see next. This is a completely custom behaviour for a slideshow and of course there is no jQuery plugin that does this by default, but after some frustration I found a plugin with an excellent API that allowed me to program it exactly how we wanted http://kenwheeler.github.io/slick/ Hope you like it.

We use DigitalOcean with a ServerPilot managed layer so you can easily add additional users and apps. Works great and we never had any outage or unexpected downtime and support from ServerPilot is really good.

I'm not exactly sure what you're thinking "combine" means here, but this field does exactly what the description says; it grabs data from other fields, mashes it all together into one big blob of (JSON) content -- and that's just about it. One very simple (yet sometimes very practical) use case is if you've got, say, 15 different text fields and you need to find pages that contain value "john doe" in any of those. Instead of doing this: $john_does = $pages->find('field1|field2|field3|field4|field5|...|field15%="john doe"'); .. you can create a cache field, select all of those fields to be cached in it, and then do this: $john_does = $pages->find('my_cache_field%="john doe"'); Not only does this look clean, in certain situations it can wildly improve query performance.

I think you can enable Cross-domain AJAX requests in your .htaccess # ------------------------------------------------------------------------------ # | Cross-domain AJAX requests | # ------------------------------------------------------------------------------ # Enable cross-origin AJAX requests. # http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity # http://enable-cors.org/ <IfModule mod_headers.c> Header set Access-Control-Allow-Origin "*" </IfModule> found in html5-boilerplates .htaccess

I agree that this can already be done with code - no question. To use a practical example, let's say we have two templates, "author" and "blog-post". The "blog-post" template has a reference field, crediting one or more authors for the post. An "author", when rendered as a page, is going to display detailed profile information about the author, and maybe list his most recent posts. A "blog-post", when rendered as a page, is going to display who the authors are, but probably in a short summary format. Now currently, the way I would implement the template for "blog-post", is I get the list of authors, and I loop over them inside the "blog-post" template. As opposed to calling $author->render() for each author, because that would render with the full template with all the details and listing other posts. So you've got the "blog-post" template now in charge of actually rendering bits and piece of "author" pages, but not using it's template, and avoiding the render() method, because it renders a full document view, where in this case, all I want is a partial. What I'm seeing, is that you actually have multiple views of the same information in different contexts. Let's say we also have an "article" template, which also has a list of "author" references - now I can either duplicate the snippet of code that renders the authors in the compact format, or I can move that code into an external include file, e.g. a separate view. But there's currently no way to formally associate an alternate view with a template. Another example would be a template that requires two different views - for example, an "article" template might have both a "teaser" view and a different (default) full article view. Currently, we can model that with an extra URL argument, and an if/else statement in the template, making the decision about which view to render. But again, there is no formal way to associate the alternative view(s) with the template. I'm not saying there has to be - it just seems like a rather common requirement, and possibly one of those things where it might be beneficial for a non-programmer (designer) to be able to add multiple views for a template, without having the programmer (me) become a bottleneck in those situations...

I can duplicate your result here. I think we must be running up against the bounds of what a default float field in MySQL will support. It looks like 6 digits max, whether before or after the point, from testing here. You could try changing it to a double from PhpMyAdmin, but I usually stick to a normal text field for lat/lng values, or for any longish floating point value that I don't need to use for greater-than/less-than comparisons in selectors. I may update this fieldtype's schema to use a double rather than a float, though I'm not positive even that will support the full scope of lat/lng values.

Ryan, thanks for this. Unfortunately it doesn't work (both api and admin saves with 4 decimals). I updated /wire/ with latest files and after that recorded this short screencast: http://www.screencast.com/users/apeisa/folders/Jing/media/b44e3208-f758-4103-8ecc-2c8849ac48f3