ryan

PW loads stuff on demand, so if you print_r $page, then that's going to trigger it to load a lot of stuff and perhaps even an infinite loop. It's best not to print_r or var_dump $page objects for this reason. A $page object is pretty light in it's default state. It gains weight based on the number of autojoin fields you have. Following that, all fields you access are loaded on demand and then become part of the page's data. To keep pages as lightweight as possible, you'd want to limit your autojoin fields to only those that you need for every instance of a $page (like the 'title' for example). While a $page is intended to be lightweight, it's obviously going to be heavier than just an ID. And by that logic you can store more IDs in memory than you could pages. Though it's rare that I would do so because an ID rarely provides much value on its own. But there are cases, and here's how you can do it. You can query any field_* table and expect that it will have a pages_id field. So if I wanted to find all pages that had the title 'Templates', I could do this: $ids = array(); $result = $db->query("SELECT pages_id FROM field_title WHERE data='Templates'"); while($row = $result->fetch_assoc()) { $ids[] = $row['pages_id']; } // ...if you later want to convert it to Page objects, there is a getById function: $matches = $pages->getById($ids); // returns a PageArray Note that getById function performs faster if it knows what template is used by the page. It is an optional param that can be specified like this: $pages->getById($ids, $template); Here's another scenario. Lets say that you want to do something like a $pages->find(), but get the IDs rather than the Page objects. Here's how you can do that: $finder = new PageFinder(); $query = new Selectors("title=Templates, template=basic-page, sort=-created"); $results = $finder->find($query); // $results is array $ids = array(); foreach($results as $result) { // each result includes: id, templates_id, parent_id and score (if rank sorting) echo "<li>Found Page ID $result[id] using template ID $result[templates_id]</li>'; } That's how you can use the PageFinder class, which isn't part of the public API, but may be useful in certain situations where you only need to interact with IDs. However, keep in mind that when you use this, you are bypassing PW's caching and such. So if you are using this to ultimately generate Page objects then you will likely lose performance by going this route. But if you have a use for thousands of page IDs and don't need to turn them into Page objects, this would be the way to go.

If you want, email or PM me a copy of your database (SQL dump) and I can try to load it here to see what the issue might be. Also, I think it would be worthwhile to grab the latest source code (2.2.0.1) to replace your /wire/ dir with the latest, just in case.

Try changing the last line to this: } while(count($entries) || count($images)); Basically replacing the "&&" (and) with "||" (or). If that doesn't do it, paste in your code so we've got the full context to look at.

Mike can you give us a lot more detail? Are you creating a page in the admin or in the API? If in the API, is this from a template, a module or from a command line script? If you think screenshots would be helpful, please include that too.

I have a feeling that your code was okay, and it was just PHPMailer that was failing... perhaps because one of the options needs to be changed, like SSL or password or something like that. That's why I think getting a look at whatever error message it is producing would probably answer it.

You are right, the picture answers it. Looks like your browser is supplying this auto completion and most likely doesn't trigger the event we're looking for when it does the auto completion. One thing you might try is after letting it populate the auto completion, hit the spacebar or some other key and see if that then makes it populate the URL tag?

Also wanted to add that using $config->styles or $config->scripts on your own site is totally optional, unless you are using some module that requires them (none of the core modules do). They were designed for use by the admin template. I rarely use them myself, but if they suit your needs on the front-end, then no harm in using them.

For a field that can contain multiple images, the value of that field is always going to be a type of array. So you'd have to either check to see if there are any items in the array, or try to retrieve the first time like Soma did. Here's how I usually check if there are any images: if(count($page->images)) { // images here } else { // no images } When it comes to a single image field, you are dealing with just one item that is either set or it isn't (rather than an array). You only need to check if it has a value: if($page->image) { // image here } else { // no image } When you use $pages->find(), $pages->get(), $page->children(), etc., you can also find pages that have a given amount of images. So if you wanted to find pages that don't have any images, you could do this: $pages->find("images.count=0"); ...or pages that have one or more images: $pages->find("images.count>0");

This may not be a safe inclusion because it's not specific enough. It's going to search all of PHP's paths for a "pw" dir before it searches the current dir. So be sure to complete that to a absolute or relative path. Absolute meaning a full "/path/to/pw/index.php" or relative meaning one that starts with a dot, i.e. "./pw/index.php" or "./index.php" or whatever it is relative to your PW installation. Also, for your API call, I suggest using wire('pages')->get() rather than $wire->pages->get().

I recommend starting with another language pack, like this one: And then just replace the existing translations with your own.

I don't have experience with PHPmailer, but would guess that the $mail->Send() is failing, since $success never gets set to true. I think the best bet here is to figure out how to retrieve the error message from PHPmailer, as I think that would likely answer the question. Also want to mention that when you finish this up, be sure to run all the fields in your $form and $required_fields through a sanitizer. Particularly any that can appear in email headers like Subject or From.

Thanks for your interest in making this language pack. While I can't help with translation, just let me know anything else I can do to help.

I have the same wish. But this is a little more complex than it sounds, so has to wait until there's time to do it right. However, shorter term the intention is that one can use an image field in a repeater to achieve something similar.

Nice work Sylvio. Quite an interesting and unique site! Why PW 2.1 and not PW 2.2?

I would consider that an upgrade.

Thanks Robert. It looks like we had a bug where the multi language fields expected you to have more than 1 language before you started using multi-language fields. I fixed this and posted the update per your GitHub report.

You are doing a great job of learning the PHP basics and asking all the right questions. Unlike what you learn with EE, everything you learn in ProcessWire (PHP) will be things you can take with you to almost any other development situation, whether in ProcessWire or not. There are two types of while() loops. A regular while loop only executes while the condition is met. It will execute 0 or more times, since the condition has to be met before it will begin looping: while(condition) { // some code } The other type of while() loop starts with a "do". Note that the condition check is at the bottom rather than the top. That means that this loop will always execute 1 or more times, since it doesn't decide whether to continue for another round until it reaches the end. do { // some code } while(condition); Like Sinnut said, the shift() function is just a way to shift the first item off the beginning of the array. I don't really know the source of the word 'shift' but I used it in PW's API just for consistency with PHP's array_shift function. If you wanted to instead pop off the last item from the array, you'd use the pop() function (which is consistent with the naming of PHP's array_pop function, and a little easier to remember). I'm not good at remembering all the PHP or PW function names off the top of my head... I pretty much always have to refer to the cheatsheet or docs.

I agree with Soma on all points. The first thing I would try is his suggestion to drag/sort the last page to the first spot. That would force it to re-populate the 'sort' field from all the pages in the list. But if that doesn't do it, I think a table repair would be the next step. Any time MySQL is producing some unexplainable behavior, a repair is a good way to go. But luckily that's not often.

I'm still not sure I'm understanding this. Are you talking about a Page reference field, where you've set the PageAutocomplete as the Inputfield? That's the only autocomplete instance that is built into PW. But even if we're talking about that, I'm not sure how that connects to the URL? Is it possible we're talking about a web browser behavior rather than PW one?

That's good to hear. From what you say, it sounds like LiteSpeed is a good web server to use with PW because it is so Apache compatible.

The behavior you see here where sometimes it allows commas and sometimes it doesn't is because it depends on what other characters are in the strong. So it'll let a comma stay in "test, test2" but not "guns n' roses, mötley crüe". It's a little too strict, and this function could be a lot smarter, so I'm working on some updates to it that I'll post later this week.

Thanks for sending me the profile Seddas--I will take a look and fix. I did actually just commit some updates earlier today that may possibly resolve this particular issue, but since I was focused on fixing another issue, I think there's only a 50% chance of that. So I will be testing this soon.

Thanks for the good description on the issue there. I finally understand it and have fixed it (I think). But I'm making some other updates to the Date Inputfield so going to be committing them all together.

Seddass, are you running the latest PW? Some fixes were put in a couple weeks ago, and those fixes may resolve the issue you are running into. Let me know if you are already running the latest or if they don't resolve it, and I'll get back to work on it.

When you enable the URL segments option for a given template (Templates > Edit Template > URLs > URL Segments) then PW will accept non-existant URLs, so long as they start with one that does exist. So lets say that you have a page called /products/widget/. If URL segments are enabled, then you could access any URL below that and it would be sent to /products/widget/. So accessing /products/widget/photos/ (a page that doesn't exist) would still get sent to /products/widget/. (If URL segments are not enabled, then of course accessing /products/widget/photos/ would generate a 404 instead.) Using the /products/widget/photos/ URL, the 'photos' portion would be considered URL segment 1. You can check the value of URL segment 1 in your template file with $input->urlSegment1. If there were another segment on there too, like, /products/widget/photos/cats/ then 'cats' would be URL segment 2 ($input->urlSegment2), and so on. The advantage of URL segments is that you can have just 1 page handling many URLs. The portion of those URLs that are translated to URL segments are not pages in PW. In fact, if you actually created a page in PW named /products/widget/photos/, then your 'widget' page would no longer receive the 'photos' URL segment, as the new photos page would then have control over it.