ryan

Try this: $pages->find("articleImageFiles|articleImageLinks!=''");

You mentioned earlier that you could see the instructions page. Just to make sure we're talking about the same thing: in the PW admin, you click "view" for the page titled "Pages Web Service", and you see this (the instructions page): Then you click the second submit button, and you get a 404? Assuming I'm right so far, what is the URL in your address bar when you see the 404?

Nice work MadeMyDay. Regarding the navigation: I think Diogo makes a good point, but stepping outside just this site, I'm wondering if a client might understand the concept of a site like this if they still have the familiar reference point of that navigation. It's kind of the difference between them thinking of it as a 1-page site, or a creatively-presented multi-page site. Not sure what's best on this particular site, but as a general thing, having that nav seems like a good thing to me.

You can always reset your password just by pasting this temporarily into any one of your templates, and then viewing a page that uses the template: $u = $users->get('admin'); // or whatever your username is $u->of(false); $u->pass = 'your-new-password'; $u->save();

When it comes to translating text from one character set to another, look into PHP's iconv() function. You'll want to run your latin1 text through this function before assigning it to a field in ProcessWire: $newPage->title = iconv("ISO-8859-1", "UTF-8", $row['HEADLINE']); With regard to the duplicates, it sounds like you already solved this. But when you are doing an import like this and it's more than a one-time thing, then you need accurate duplicate checking. The best way to get that is to make sure that you are the one assigning the 'name' field, and that you aren't letting ProcessWire auto-generate it for you: $name = wire('sanitizer')->pageName($row['HEADLINE']); $newPage->name = $name; If there is a possibility that $row['HEADLINE'] will ever change on future imports, then you'd be better off using a separate ID field to match things up. I typically add an integer field named 'old_id' to my template, and that would contain the primary key from the old data. Then you would check that when determining whether its an existing page or a new one. Last thing I want to mention is that you might be better off caching your $parent page above the loop where you are creating the pages: $parent = wire('pages')->get('/news/'); // .. then in your loop: $newPage->parent = $parent; The reason for this is that ProcessWire clears its own cache of loaded pages every time you save(). So you'd end up re-loading that $parent (/news/) on every loop iteration. Whereas, if you've kept a copy of it in your code ($parent) then you can continue using the same one without reloading. Basically it's just a little more efficient/faster, though probably doesn't matter much.

Make sure your ProcessWire version is up to date (but I'm assuming it is). The default/instructions page has some tools for you to test the service. When you submit those, do they work? Check also your module settings, as ServicePages limits the queries to only the templates and fields you have defined as allowed. So in your example, if you haven't allowed the "picture" template, then the request is going to fail.

I think that doing a hook replacement of buildFormRoles should remove that entirely. If you hook in before and set it to replace, then it'll never even call PageEdit's buildFormRoles method. Set $event->return to return a blank InputfieldWrapper, InputfieldHidden or InpufieldMarkup. public function hookBeforeBuildFormRoles($event) { $event->replace = true; $event->return = new InputfieldWrapper(); } (on mobile so can't test at the moment, but think that should work)

Strange, I replied to this yesterday and now don't see my message. I'm wondering if I forgot to hit post or something (or maybe I'm losing it?) Anyway I fixed this yesterday morning so searching for CSV should now work. I switched it to use '%' and added the summary, description, class_name and instructions fields to the search.

I'm thinking it shouldn't affect performance too much, but haven't tried -- I'm curious what you find here. Since the primary need is just to not show the pages in PageList, you could set it to do this only when ProcessPageList is active: if(wire('page')->process == 'ProcessPageList') { } No problem. I've just made it hookable and will push to GitHub within the next hour (along with some other minor updates).

I agree with Teppo, this is really a great site.

Thanks for testing it, I've committed the changes so they now appear in 2.2.6.

Thanks Soma, this clarified it for me.

Soma, this looks cool, but I'm not sure I fully understand exactly what it does. I've been looking at the code and the function arguments for a bit here, as well as the other thread, and a little confused?

It sounds like the template you are trying to retrieve does not exist. I have a feeling there are some extra characters in $page->form_name, and that's why Soma's suggest to trim() and strip_tags() may be a good one. It's very possible you've got some textformatter on there putting "<p>" tags around it, or doing something. So make sure no textformatters are manipulating the field (can be seen on the details page). You can examine exactly what is in $page->form_name by doing this: echo "'" . htmlentities($page->form_name) . "'"; I'm guessing you've got something in there more than just the form_name, or perhaps it's completely blank.

I'm good with a toggle. I don't want to change the existing default behavior, just because it's been there awhile, and some people may be relying on it (including me). So dont want to produce any surprises. But I've added a toggle called 'arrayToCSV' that you can put in the $options. If you set that to false, then it'll put it in the format that you prefer. I've attached a copy of this file. Can you test to confirm that this works the way you were thinking and let me know? If all looks good, I'll commit it to the source. MarkupPagerNav.module

Glad to hear you are making progress with this! ProcessWire handles the template-based permission checking at the DB query level, so something like PageList assumes that anything it gets is okay to include in the output. Having the permission check at the DB query level is necessary to ensure that things like pagination and 'total' counting are accurate. Though if you aren't often paginating 'pages with permission' vs. 'pages without permission', in the same list, then this may not be a concern. Since PageList is going to show whatever it gets from $pages->find(), I think your best bet is to hook after $pages->find() and specifically remove the pages the user doesn't have access to: public function hookPagesFind(HookEvent $event) { $items = $event->return; foreach($items as $item) { if($page doesn't have the role(s) you want) { $items->remove($item); } } $event->return = $items; } The main thing to note here is that since you are performing this filtering after find(), the quantity of pages returned may be less than what you've specified in your "limit=n" selector.

Those commented translations in default.php are kind of a placeholder/short cut, and you are seeing a side effect of it. Typically translatable text consists of static text in a file. But the translation being done in this instance is actually on dynamic text. So the commented translation calls are picked up by the parser as translatable copy, but obviously those function calls never execute (since they are commented). Instead, the admin template runs the navigation titles through the translation function, with dynamic text (actual page titles). So if it encounters one of those placeholder words/phrases in a page title, a substitute translation will get used when available. When you removed the __("Templates") line, ProcessWire considers that abandoned since it no longer appears in the file. But "abandoned" is a runtime state, not a permanent one. That state exists only to notify you during translation time what words/phrases no longer appear in the file. The file still requested a translation for that word "Templates" at runtime, and it found that there was one, so it delivered it. You would have had to delete the abandoned translation to fully get rid of it.

I also like how if you click on 'contact' it pops out a bar from the top. A nice touch.

Delete the ones you want to replace and drag them into the file field. I suppose you could also replace them via FTP, but you wouldn't want to do that for new files. I understand it would be ideal to just be able to drop and replace in 1 shot, but don't have an easy answer for that yet. I think they would have to be split into two separate file fields to do this. Might be a good thing to add during one of the next updates to LanguageSupport. But this would provide some separation between core and custom stuff, making it easier to maintain, which is what I think you are alluding to. Sounds good to me.

Why so many template files? Is there any duplication between what you are doing from one template file and another? If so, remember never to repeat yourself and keep reusable stuff in separate includes, functions or modules. Also consider whether the different template needs might instead translate to stylesheets. But I know you have a good handle on all this stuff, so going to assume you really do need a lot of template files. In that case, I would suggest doing something like you indicated and considering your templates to be something more like template groups instead. Create a structure of pages that represent your "sub templates". Make them selectable, so that when you edit a template, you'll have a select box where you can choose a sub-template (with a field named sub_template). You can translate that page selection to a filename off a subdirectory in your /site/templates/ directory. For instance, lets say you are creating a page with template "news" and you want to have sub-templates of cnn, nbc and abc. You'd have a page structure like this to represent them: /sub-templates/ /news/ /cnn/ /nbc/ /abc/ And a template file structure like this to represent them: /site/templates/news.php /news/ cnn.php nbc.php abc.php Your news.php file might look like this: include("./news/{$page->sub_template->name}.php"); What I'm trying to get at here is that you can create a structure of pages to represent a structure of templates.

This is a fun question to answer, so thanks for asking it. It really gets down to much of the motivation behind the system. For me it really comes down to time. Time is the most important thing to me. I'm getting old and need to focus on the things that give me more time, and that's what it's all geared around. For others, it's money. But time is money. Either way, you have to ask: "what is saving me time?" That's all you need to know to answer the question. But here's the long version: How much time does it save you to use a template engine vs. PHP API? I would suggest that using a template engine saves you zero time (maybe even costs time) vs. using a clean PHP API like in ProcessWire. Ultimately you are just typing different characters with a template engine, in about the same quantity, to do the same thing (example). Nor is a template engine performing any heavy logic, thinking or processing behind the scenes… it's mainly just substituting one thing for another. It's not saving you any time or mental/logical energy. It's this whole abstraction layer taking up space that isn't contributing anything to the bottom line. So the benefits of a template engine aren't very clear, relative to using something like ProcessWire's API. And I don't think it matters whether you know PHP or not, as the learning curve is identical between PHP and a template engine, for accomplishing the same things. The only difference is that PHP will go much farther, when/if you want it to. Then look at the amount of time it would take you to construct raw DB queries (or through some abstraction layer like ActiveRecord). A simple selector that you write in a few seconds translates to a rather long and complicated SQL query that might have taken quite some time to create and optimize manually. Whether in ProcessWire or somewhere else, to create the SQL query, you would have had to maintain internal knowledge of the database, tables involved, indexes, left and right joins, orders, grouping, limits, security and much more… So I would suggest that ProcessWire's selector syntax is saving HUGE amounts of time (and thus cost) by abstracting away a whole lot of technical details and optimization. At the same time, it's part of a larger system that has also abstracted away the complexities of DB design and optimization, and brought it all into the context and thinking of a website. You don't need to know anything about databases or indexes, or that they even exist. I would also suggest that ProcessWire gives one the impression that they can easily pluck data from anywhere in their site as if it was already in memory… and in the context of a website, not a database. In terms of time and cost savings, is there any comparison between this and a template engine?

Just want to make sure I've got it written down as to what specifically would help: Addition of an option to support intentionally-empty translations, and not have them count towards the untranslated count. Addition of a tool that finds all translatable files and also calls out those that don't have any translations (i.e. new files) Addition of a tool that bundles all translation files into a ZIP or something like that, ready for download. Does this sound right, or anything else? I can't get started on these right away, but thought it would be good to get them written down so they can become part of the roadmap at least.

I've never even heard of allow_call_time_pass_reference, so haven't ever put it into PW's code anywhere. Though wondering if some kind of '&' usage is triggering it or something. Is there any specific page that it's occurring on, or does it appear random? I'm also wondering PHP might be picking this up from a php.ini or .htaccess file somewhere on your server (given that it says line 0 of Unknown)?

Nico I couldn't duplicate here, so probably need to know more specifically what you were trying to change in the TinyMCE settings. I tried adding h1 to my theme_advanced_blockformats and it worked just fine with the two languages I tested it with in a TextareaLanguage field. The only thing I could see from your screenshot is that you had the theme_advanced_blockformats pasted into your theme_advanced_buttons. As far as I know, those don't represent valid button tags for TinyMCE. But just in case, I went and tried them myself both with Textarea and TextareaLanguage, and they don't produce buttons in either... so I'm assuming they aren't valid. But maybe I'm not looking at the right thing in your screenshot. Let me know how to see the error you are talking about.

Thanks Nik! I have corrected that and push the update to GitHub.