Search the Community

I myself am a static man - I love Middleman, Jekyll, Stacey & Kirby. I'd really love it if there was some crossover, something where you'd write your website, build it and then upload it having some tiny PHP router for doing tiny bits of runtime changes, like including different files based on $ajax, sending forms, etc.

Translation doesn't work. Or am I missing something? ProcessLanguageTranslator: Found /site/modules/ToolsTimeAgo.module ProcessLanguageTranslator: That file has no translatable phrases Translation doesn't work for runtime variables as the string. And I thought the _() have to be on 1 line, but I could be wrong.

If you don't specify a permission, then your module is available to all admin users. If you specify an existing permission, like 'page-delete', then your module's execute() method(s) will only be available to users that have that permission. You can also have your module install a new permission, and then set it as the required permission. Example: $p = wire('permissions')->add('page-draft-control'); $p->title = 'Ability to create draft pges for edit/preview'; $p->save(); I think that the above is probably not exactly what you are looking for. In your case, you are using a Process module as an 'autoload' module, so your hooks are getting attached regardless of any specified permission (since that permission only applies to 'execute' methods). What you should do is check that the actual $page is editable() before performing runtime actions: public function hookPageListActions(HookEvent $event) { $page = $event->arguments[0]; if(!$page->editable()) return; ... } public function executeCreate() { $page = $this->pages->get((int) $this->input->get->id); if(!$page->id) throw new WireException("Page doesn't exist"); if(!$page->editable()) throw new WirePermissionException("You don't have access to edit that page"); ... }

You can't use any operator except '=' when querying path or url from the database (like when using $pages->find). This is because the path doesn't actually exist in the database, so there's nothing to perform comparisons on. It is generated at runtime based on a page combining its name with the names of its parents. It worked with '=' because we pulled a few tricks to convert a path into a big left join statement, in an attempt to match it. And this actually works very well. But it doesn't translate quite as well to other operators. I should have had the engine throw an exception when you used an operator it didn't support for that. Instead it just switched it to an '='. So I've updated it so that it now throws an exception instead. I've also added a new module to the core, called PagePaths. When you grab the latest dev branch, do a 'check for new modules' and you should see it. Once you install that, it goes and sets up a table with all the page paths and a means of querying them. This enables you to use any operator when querying path or url, including all the partial text matching ones like %=, *=, ~=, ^=, $=. As a side effect, this module also brings potential performance improvements to other queries, as it eliminates the need for the left join trick I mentioned above. (Though in my initial tests, it doesn't seem to be a measurable improvement). I will probably have this module installed by default for new installations of 2.3. But won't have it auto-install to existing installations. That's because it has to generate an index of all pages in your site--a potentially resource consuming process. For instance, Antti's 100k page site probably won't work with this, as it's no small task to go and build an index for 100k pages after the fact. But if you aren't running a massive site already, this module is one you probably want on most sites, so I went ahead and included it in the core.

ProcessWire Concatenate Fieldtype Fieldtype that concatenates the values from one or more other fields at runtime. The value can contain additional formatting and/or words as needed, which you define in your Concat field settings. Example Problem: Your system has a first_name and last_name field, and you want to have a separate full_name field composed of first_name and last_name, without redundancy. Solution: You would create a new Concat field, click the details tab, and enter "first_name last_name" (the fields you want to concatenate) in the settings. Other Potential Uses Having a field that combines the value of two or more others, without the redundancy of separately stored data. Defining a custom “label field” for select boxes, like those used with the Page field. Defining a custom label for your Page List that includes your own formatting. Defining an alternate variation of a text field that uses a different text formatter. Considerations The value for this fieldtype is generated at runtime and thus no data is stored in the database. This is good because there is no duplication. However, it also means that you cannot directly query a Concat field from $pages->find(), for example. If you happen to change the name of a field being used in a Concat field, you will have to update the name in your Concat field settings as well. By design, Concat fields do not inherit the text formatters of the fields they concatenate. You define these separately with the Concat field. Because this is a runtime-generated field, there is no Inputfield associated with it. How to Install Install the module by placing FieldtypeConcat.module in /site/modules/. Check for new modules on the Modules screen in the ProcessWire admin. Click Install for the Concat Fieldtype. How to Create a Concat Field Under Setup and Fields create a new field using type Concat. After entering the new field name and label, click Save. Click the Details tab and enter one or more field names. Separate them with whatever spacing and punctuation is appropriate. Optionally choose one or more Text Formatters. If you are not sure which, “HTML Entity Encoder” is a good default to use. Save. Add your new field to one or more Templates. How to access the value of a Concat field This is no different than accessing the value of any other field. If your Concat field has the name “full_name” then you would output its value like this: echo $page->full_name; Download PW Modules Site: http://modules.proce...eldtype-concat/ GitHub: https://github.com/r...FieldtypeConcat

Diogo, you don't have to do it manually, just a save hook. Giving you back a simple find() on front-end it is worth considering it. It would also even work in admin sorting by the field and so on. Sure an simple page array where you store the height of the first image in a runtime property to then sort by it is also a way. But then just add a line or two more to save the result to the page and you already have a "function" to do it automaticly. $pa = new PageArray(); foreach($pages->find("template=xyz") as $p){ $h = $p->images->first()->height; $p->img_height = $h; $pa->add($p); } foreach($pa->sort("-img_height") as $p){ $img = $p->images->first(); .... }

You won't be able to do this at the DB level because width/height is not stored in the DB. As a result, you won't be able to query the DB based on height of an image unless you manually store it yourself in some other field. However, I think you could probably do a $page->images->sort("height"); at runtime.

Yeah I tested code and found some issues. I create a code that works. Study how it's done and the changes. $page needs to be retrieved different, and it had some logik faults, it needs to add or remove $page, not $s_team... Biggest issue with save hooks is that when you save a page in the module it will get called endless recursive. To prevent this we save a skipme to the pages saved on runtime to it does skip them. Also added some additional checks for if there's no pages selected at all, to remove all references. Here a new working proof of concept module: https://gist.github.com/4335296

Hey, thanks for answering. I am logged out when performing the benchmark (see previous reply). I also tried enabling cache for "Guests and logged-in users", but that didn't make an impact. I did configure the cache under Template settings, and I am hitting only one page. The module I activated is called FieldtypeCache, and its summary is: "Caches the values of other fields for fewer runtime queries. Can also be used to combine multiple text fields and have them all be searchable under the cached field name. " I am pretty new to ProcessWire so that might not have been the correct thing, but Template cache isn't working well for me. I guess what I am asking is: 1.) Is there any way to verify that the template cache is working properly? 2.) Is it normal for cached pages to generate mysql queries?

Did some investigating here. If I'm right, it's not a bug per se, but an undesirable behavior. Try changing your code to this: require('./index.php'); // this is the ProcessWire index file for bootstrap $wire->pages->setOutputFormatting(false); echo $wire->pages->get('/videos/')->render(); echo "\n\n\n\n\n==============================\n\n\n\n\n\n"; echo $wire->pages->get('/people/')->render(); That fixed it in my case. The reason was that calling setOutputFormatting() on a page only sets the outputFormatting for that page. If your page's template happens to be loading other pages, they will be loaded with outputFormatting off. By setting the default output formatting state before you render(), you correct that issue. This is only the case when you are rendering from a bootstrapped script, because that default outputFormatting state is pre-set to false. In any other situation, you wouldn't have to do this. I think I can make this a lot simpler. I'm just going to update $page->render(); to take care of setting the right outputFormatting state for itself and the system before it attempts to render a page. If that change didn't fix your case, then go in and check the template(s) for the pages that are being rendered. Do you have any include() statements that should be changed to include_once()? This would be the case if you had any function definitions in include files. If you have any function definitions in your main template file, then you'd want to do this instead: if(!function_exists("my_function")): function my_function() { // do something } endif; Since your two page render() calls are happening in the same PHP runtime instance, you just have to watch out for any duplicate definitions or includes. Let me know if any of this solves it there?

The only way to prevent this issue is to install "PageLinkAbstractor" module and it will give you additional options on textfields. This will parse urls and add subfolder on runtime. http://modules.processwire.com/modules/page-link-abstractor/

URL segments are a runtime thing that ProcessWire doesn't know anything about. It only knows where you want to allow URL segments, but not what they are or what you plan to do with them. It's up to you (in your templates) to look for the URL segments you want to act upon. Likewise, it's a best practice to throw Wire404Exception(); when your template gets a URL segment it doesn't recognize. If you want to avoid any possibility of there ever being a collision between a page name and a URL segment, then you wouldn't use URL segments on pages that had children where the URL segment names had potential similarity with the child names. However, I think it's okay to use them in the instance where you are because it seems like there is no chance for a real-world collision here. I would feel comfortable using the URL segment "category" in this instance just because it doesn't seem to be consistent with something that would ever be used as an article title (though that may be just me).

We force a non-www on processwire.com, but it seems that not many sites do that for whatever reason. If you want to do that, here's the code you can use in your htaccess (replacing processwire.com with your domain): RewriteCond %{HTTP_HOST} ^www\. RewriteRule ^(.*)$ http://processwire.com/$1 [R=301,L] This isn't technically part of ProcessWire's runtime configuration because the rules in the htaccess file are what ultimately gives control to ProcessWire (they are executed before ProcessWire is).

This fieldtype wouldn't even need a db-table, since value is always 0 (well, it is 1 at the runtime but that will never get saved). So there probably is some code that can be removed (this was build from Checkbox fieldtype).

Technically the only module groups built-in are those that start from a base class: Process, Inputfield, Fieldtype, Textformatter, ModuleJS. The headlines you see in the Modules list are runtime grouping of the first word in a modules' class name. Conveniently, this works with our our base-class module groups, but it does also extend to other modules with similar naming conventions. For the most part, I think it's better not to use one of the base class names for your module unless it extends that class. In the future, we may want to offer other types of runtime grouping options like: modules related by dependency, autoload modules, etc. Related modules in a group may have different naming conventions by need (like a related module set that has it's own Process module, Fieldtype and perhaps others) -- these aren't expected to appear together in the modules list.

It's not a good idea for 'autoload' to be the only condition necessary to add script or css/style files. That's because some (including me) use things like $config->scripts and $config->styles on the front-end of sites, and don't want it to be populated with files irrelevant to my site. Furthermore, we can't assume that we always know what ProcessWire is being used for (it might not have anything to do with HTML), so it's just taking up extra memory if some autoload module is populating filenames when they won't ever be used. This is why none of PW's modules that deal with script/style files are autoload, and also why Process and ModuleJS module interfaces are not autoload. Process modules are on-demand, but if you have a Process module that you've made autoload, then you'd want to manually load any script/style files in the relevant execute() method -- this ensures they won't get loaded unless they'll actually be used. The ModuleJS class is different, as it's really not intended to be autoload at all, so there's not really any use in combining ModuleJS with autoload. The whole idea of javascript or css is specific to a runtime and on-demand context. And this is how it's happening in the admin template, as it is what ultimately triggers the JqueryCore and JqueryUI libraries to be loaded. And this is the time that they get placed into the $config->scripts array. So we'd just have to find some way to hook after that takes place, but before the markup of the page is generated. I think this may work for an autoload module: public function ready() { if($this->page->template == 'admin') $this->addHookBefore('ProcessController::execute', $this, 'hookExecute'); } public function hookExecute(HookEvent $event) { $this->config->scripts->add(' your script file '); }

I see what you mean. Sorry for the confusion this may have caused. I will think more here about how to handle this. I don't want it interfering with API usage such as yours, but do want it to be able to still work with any login form (whether ProcessLogin or a custom one). Initially I'm thinking maybe I should just have it throw an Exception rather than a $this->error(). Errors communicated via $this->error() require something to report them (like the admin template), so this could be hard to find in API usage. Whereas an Exception would be hard to miss. Beyond this, I think a way to disable SessionLoginThrottle at runtime would be worthwhile for a case like this too.

Sorry I missed this before. Got your PM so replying here. I'm still having some trouble understanding the question, but think I follow a bit. It sounds like you are trying to use $pages->get() to retrieve a page via a path like /a/b/ where /a/ is an actual page and /b/ is a urlSegment. A path with a urlSegment in it doesn't resolve to an actual page except when requested from the browser. So you can't use the API to retrieve a page by path with a urlSegment in it -- you'll get a NullPage. You would want to use just the /a/ (the part that is actually a page) in your API call. urlSegments are just runtime things for you to branch from in your template. They don't represent physical pages to the API.

Given that we don't know what the user's fields or types will be ahead of time, there isn't really any way to document it with the Page class (that I know of). The function that handles this particular situation (setting a value to a $page->pageref) is FieldtypePage::sanitizeValue(). It is currently documented (with phpdoc) to indicate what it's for and all the values that it accepts and returns. But doesn't say anything like "usually you'd set a PageArray" because I don't think anyone is going to be looking here unless they already know the routes that setting a value to a Page takes. Ultimately, the best way to document this sort of stuff may be outside of the code itself and in online documentation specific to each Fieldtype. I think the cheatsheet is a great resource for this stuff. Though I don't think there's anything specific to the situation we're talking about just because it's one of those things specific to a FieldtypePage. So I think FieldtypePage probably needs it's own manual. That's what we're doing now. But I'm not sure how to communicate to someone that when they set (or get) a value to a Page, a lot of decisions go on behind the scenes. In our particular case of setting a $page->pageref, the path would be this (pseudocode): $page->set('field_name', $somePage); { // if 'field_name' is a custom field confirmed by the page's fieldgroup, use setFieldValue() $this->setFieldValue('field_name', $somePage); { // get the Field object $field = $this->fields->get('field_name'); // let the Fieldtype sanitize the value before setting it to the $page, i.e. convert Page|int|string|array to PageArray $value = $field->type->sanitizeValue($this, $field, $somePage); } } That last line is where the magic happens. The sanitizeValue will accept $somePage in various types, but always returns a PageArray back to the page. If it gets something it doesn't like, then it's either going to throw an Exception or refuse it (depending on what the Fieldtype author thinks is appropriate). Something similar happens when you get() a value from a Page, tough even more behind the scenes: $page->get('field_name'); { // if field_name is a custom field confirmed by the page's fieldgroup, use getFieldValue() $this->getFieldValue('field_name'); { $field = $this->fields->get('field_name'); $value = parent::get('field_name'); // check if it's already loaded if(is_null($value)) { // value isn't yet loaded, so load it $value = $field->type->loadPageField($this, $field); if(is_null($value)) { // if no value then set a default (like blank PageArray) $value = $field->type->getDefaultValue($this, $field); } else { // convert value to runtime type, like array of ints => PageArray of Pages $value = $field->type->wakeupValue($this, $field, $value); } } // if output formatting is on, let the fieldtype modify it for presentation (if it wants to) if($this->outputFormatting) $value = $field->type->formatValue($this, $field, $value); } } I'm not exactly sure how to document this beyond the pseudocode above, or if it even matters. I'd rather people think of it as just setting or getting values and everything works. But it seems like a separate page of documentation for each Fieldtype might help to answer some of the questions.

Perhaps having permissions at the template level should be a pre-requisite to making them definable at the page level? Meaning, if you didn't have this module installed, then the permissions would need to be setup such that the user would be able to create the pages. I thought this was the case before, but might not be remembering it correctly. This seems like a good way to go. It should also probably return false when the template defines access that doesn't include the user's role. So if you use the strategy above, this hook would be more about selectively denying access than allowing it. Maybe best to remove these fields entirely from the form at runtime using the ProcessPageEdit::buildForm hook: public function hookBuildForm(HookEvent $event) { if(wire('user')->hasRole('paakayttaja')) return; $form = $event->return; $field = $form->get('view_roles'); if($field) $field->parent->remove($field); $field = $form->get('edit_roles'); if($field) $field->parent->remove($field); $event->return = $form; }

Gazley, I think appending your special page like you intend is a good way to handle it (PW should take care of duplicated pages in array). And runtime sort sounds good to me too. So this is basically a cheer up post

I've done something like this before and just ended repurposing the image description field to store the external link URL. But if you want to be able to have both a description and a link, then you would put both your description and URL in the field, and just be consistent with how you put in the URL so that you can easily parse it out at runtime. For example, lets say you decided that you would always put in your description first, and follow it with the text "@http://domain.com/" (using the '@' to indicate to yourself it's a URL), so a full description might look like: Then you might parse it out at runtime like this: foreach($page->photo as $image) { $description = $image->description; if(strpos($description, '@') !== false) { list($description, $link) = explode('@', $description); } else { $link = ''; } $out = "<img src='{$image->url}' alt='$description'>"; if($link) $out = "<a href='$link'>$out</a>"; echo $out; }

With regard to your original suggestion, does the link's href get resolved at run-time or by selecting the target page in TinyMCE, does it just literally embed the path as a string so, no dynamic find() call at runtime?

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 would also go for a structured page tree and see the page tree as the main repeater. Edit: need some sleep.. so also what I wanted to add you could keep the structure ...->book(page)->runtime(repaeter-range). So if the level of information becomes 1 dimensional use a repeater there i.e. runtime has a repater for range. Book1 ->Runtime1 ->Runtime2 - range1 - range2 Book2 ... Also depends a lot on how you want to be able deal with these data. Maybe some thought about what you want to be able to do with it later i.e. if storing data in json format or comma separated strings, you'll have hard time to filter content based on that. Using a page structure will, at the best, let you use simple PW selector queries to filter or search the data.