ryan

Hi Jose, What browser are you using? Wanted to check, just in case. Then I'll go in and try to duplicate. Thanks, Ryan

Yeah but it shouldn't prevent the installer from running... The installer will just say "this dir isn't writable, and it should be". Since it appears the installer threw a fatal error before even running, I'm thinking all the files got unzipped into one dir (root) rather than in the proper structure. But so far it's a mystery.

I'm interested too. I didn't realize some of the language variations you mentioned. How do other CMSs do it in Slovak? Especially the issue you mentioned about different words depending on number of pages (1, 2-4, 5+)?

This is consistent with what's being planned. A "channel" would be defined as a selector or combination of selectors that can lead to a group of pages outside of the page tree. For instance: template=news, sort=-modified That would be a selector that lists all news items regardless of where they live in the tree structure, and places them in reverse chronological order according to when they were last edited. So I think of that as a "news" channel". If you wanted to do it from one of your templates, you would do this: $items = $pages->find("template=news, sort=-modified"); echo $items->render(); // or iterate and display your own fields I'm thinking of this channel view as being kind of an advanced search engine, where you can build a selector to look at a particular view of pages (channel). Then you can perform operations on the pages together as groups. You could predefine your own channels for later use in the admin or the API. Some parts of the admin would also predefine their own channels as well. For instance, there would be a link for each template in "Setup > Templates > Template" to display all the pages that use that template. The nice thing about this channel view is that it will be relatively easy to implement since all the page retrieval, field matching and pagination is already done... it's just a matter of building a nice interface around it. The only reason I haven't done it yet is because in my own sites I usually build the channel views on the front end of the site (with templates). Many of them make it in the public site, as views that are useful on the admin are very often useful to the site's users too. Also, I wanted to add that the existing Pages tree is customizable in terms of sorting and what fields it displays. http://processwire.com/talk/index.php/topic,120.msg749.html#msg749

In your /site/config.php there is a setting in there called: $config->loginPageID = 23; Change 23 to the ID of the page you want to be the login page. If you want to use a given login page only in some instances, I believe you can also change that $config item at runtime. For example, you might put this in some main template for your site: $config->loginPageID = $pages->get("/tools/login/")->id; I haven't tried this, so let me know if it doesn't work and I can find another way to do it or make it part of the template config as you suggested.

Looks good! I didn't do a lot of testing with the function I posted previously, so if you find any bugs that aren't easy to resolve, just let me know and I'll fix them.

I think it's possible that your archive didn't unzip properly. Can you double check that these files were created in your web root when you unzipped the ProcessWire ZIP file: /index.php /site/ (directory) /wire/ (directory) ...and some readme text files... If you see both /site/ and /wire/ there, that will help us to rule out a couple of things. Let me know what you see either way. If you'd like, create a file on your server called test.php with nothing but this in it: <?php phpinfo(); Then load that in your browser. Post the URL here if you are comfortable doing so, or email me the result. Remember to delete the test.php file once it's no longer needed.

I think we can automate the field creation part relatively easily. My plan was to add an Export/Import option to Admin > Setup > Fields, and it would basically export a JSON profile of all the fields you selected. Then you could paste that profile into another site into the "import" textarea, and it would create all the fields. The same thing could probably be done at the template level too. The idea you mentioned of a module is also a good one, though I'd probably be inclined to do the export/import described above instead. But here's how you'd go about doing the module if you wanted to. The module would exists to add the fields and templates needed for news. When you click "install" on that module, it would create the fields and templates automatically just with API calls. For example, here's how your module code might do it in it's ___install() method: <?php public function ___install() { $summary = new Field(); $summary->type = $this->modules->get("FieldtypeTextarea"); $summary->rows = 3; $summary->name = "summary"; $summary->label = "Summarize this news item in 1 paragraph"; $summary->save(); $datetime = new Field(); $datetime->type = $this->modules->get("FieldtypeDatetime"); $datetime->name = "datetime"; $datetime->label = "Enter a date"; $datetime->dateOutputFormat = "m/d/y"; $datetime->dateInputFormat = "m/d/y"; $datetime->defaultToday = 1; $datetime->save(); $fieldgroup = new Fieldgroup(); $fieldgroup->name = "news"; $fieldgroup->add($this->fields->get("title")); $fieldgroup->add($summary); $fieldgroup->add($datetime); $fieldgroup->save(); // copy your default news.php template to /site/templates/, assuming your server will let you... copy($this->config->paths->YourModuleName . "news.php", $this->config->paths->templates . "news.php"); $template = new Template(); $template->name = "news"; $template->fieldgroup = $fieldgroup; $template->save(); } Because we don't have the documentation complete to the level of detail of individual fieldtypes, you'd currently have to look at what was configurable with each field. The simplest way to do this is probably to view the source when editing that field in the Fields editor, and looking at what configuration options are available under the "Fieldtype Settings" and "Inputfield Settings". Or just ask me. You might have your module add a hook or two, like PageArray::renderNewsItems() or something like that, if it was helpful to do so. <?php public function init() { $this->addHook("PageArray::renderNewsItems", $this, "renderNewsItems"); } public function rnederNewsItems(HookEvent $event) { $pageArray = $event->object; $out = "\n<ul class='nav'>"; foreach($pageArray as $page) { $out .= "\n\t<li><a href='{$page->url}'>{$page->title}</a> {$page->datetime} {$page->summary}</li>"; } $out .= "\n</ul>"; $event->return = $out; }

I think you are both right. Having the two buttons would be great for people that routinely need to do both. But it's also true that it's one more thing to think about. On the page editor, it might be nice to have a collapsed field at the bottom that says "After Save...", and then radio buttons that let you choose: 1. Continue editing 2. View page 3. Return to List 4. Create new sibling page So you wouldn't see those options unless you clicked on the "After Save..." label to open it up. A checkbox would let it optionally keep your setting. This is kind of a power-user thing, so this functionality would be in an optional add-on module rather than something built into the core. Personally I would only use #1 and #4, but it sounds like #2 and #3 would be popular with other people too. For other types of editors (not page editor) it would be similar, but without option #2 of course.

I also need to make a new HelloWorld module to put in there too. The one that comes with it now is kind of specific to the Skyscrapers profile, which isn't used by many people.

I agree. I think this is something we'll definitely have to do. Would be great to have a 1-step backup that includes database and site files. Though it could be a slow process for very large sites.

Looks like great solutions. Here's one more: <?php function treeMenu(Page $page = null, Page $rootPage = null) { if(is_null($page)) $page = wire('page'); if(is_null($rootPage)) $rootPage = wire('pages')->get('/'); $out = "\n<ul>"; $parents = $page->parents; foreach($rootPage->children as $child) { $class = ''; $s = ''; if($child->numChildren && $parents->has($child)) { $class = 'on_parent'; $s = str_replace("\n", "\n\t\t", treeMenu($page, $child)); } else if($child === $page) { $class = "on_page"; if($page->numChildren) $s = str_replace("\n", "\n\t\t", treeMenu($page, $page)); } if($class) $class = " class='$class'"; $out .= "\n\t<li>\n\t\t<a$class href='{$child->url}'>{$child->title}</a>$s\n\t</li>"; } $out .= "\n</ul>"; return $out; } Usage: <?php // no params: print out tree menu from current page to root parent echo treeMenu(); // or specify what you want it to display echo treeMenu($page, $page->rootParent);

Sounds good. I will put together a code sample. I'm leaving to pick up my daughter from school now, so may not be back online for awhile. But I will post as soon as I can.

Strangely, there is a /site/modules/ in the master copy of my default site profile. But you are right that the dir doesn't exist in the git clone or the installation zip. I'm wondering if Git is ignoring it because it's empty... if need be I'll put a "hello world" module in there as a placeholder.

I think you are doing a great job of understanding this stuff. I haven't actually written the documentation for fieldtypes and inputfields, so I'm impressed that you seem to have figured this out on your own.

Are you looking for something that generates a nested list from current page down to homepage? That's what it looks like, but I just wanted to double check.

Great it looks like it works for me once I added those! Cool fieldtype. My computer doesn't recognize something about the language/localization, as all the buttons are a series of question marks. But I think that's just because my computer must not have that language installed. I'm wondering if it would still work if you output those two scripts from your formatValue function, since you are already outputting an inline script there? Though it may be that Google Maps requires it to be loaded in the <head> section, I'm not sure. Also, I recommend placing your GMap module in /site/modules/ rather than /wire/modules/. This is because /site/modules/ is for user-installed Fieldtypes, whereas /wire/modules/ is for Fieldtypes that are permanent. When you upgrade ProcessWire, you replace the entire /wire/ dir, so you don't want to put anything custom in there. Whereas everything in /site/ is custom to your site, so any modules you put into /site/modules/ won't get overwritten when you upgrade ProcessWire.

What is the context of where that error occurred? Are you trying to load ProcessWire from Drupal? If so, it sounds to me like Drupal probably has it's own "User" class that is conflicting with ProcessWire's. You may be better off using ProcessWire as a web service in this case. That RSS feed module I posted yesterday would be a great way to pull the data into Drupal.

I installed it and tested it – very cool! It looks like you already know how this all works. And it looks like your Fieldtype is nearly functional on the front end too. This helps me to see what you are doing, and I should be able to answer any questions you have more easily now. Actually I've been wanting to make a Google Maps fieldtype, so am happy you are making one already. Just let me know if there is anything I can do to help. Thanks, Ryan

Sounds like a good idea to me. It's possible it may be easy to implement, but I need to do a little more research.

For any page where you want to move it, just get the parent page, and set the target page to have that parent, and save: $page = $pages->get("/home/mypage/"); $page->parent = $pages->get("/"); $page->save(); or if you want to do it on one line. -- $pages->get("/home/mypage/")->set('parent', $pages->get("/"))->save(); You'd use the same method to change a bunch of pages: $parent = $pages->get("/"); foreach($pages->find("parent=/home/") as $page) { $page->parent = $parent; $page->save(); }

Absolutely! Here is a simple, but functional example for both login and logout templates. You would want to replace the markup with your own markup or includes. Likewise you'd want to change the redirects to redirect to whatever page you want them to go to after completing a login. /site/templates/login.php: <?php if($user->isLoggedin()) { // user is already logged in, so they don't need to be here $session->redirect("/somewhere/"); } // check for login before outputting markup if($input->post->user && $input->post->pass) { $user = $sanitizer->username($input->post->user); $pass = $input->post->pass; if($session->login($user, $pass)) { // login successful $session->redirect("/somewhere/"); } } ?> <html> <head> <title>Login</title> </head> <body> <form action='./' method='post'> <?php if($input->post->user) echo "<h2 class='error'>Login failed</h2>"; ?> <p><label>User <input type='text' name='user' /></label></p> <p><label>Password <input type='password' name='pass' /></label></p> <p><input type='submit' name='submit' value='Login' /></p> </form> </body> </html> /site/templates/logout.php: <?php $session->logout(); ?> <html> <head> <title>Logout</title> </head> <body> <h1>You have logged out</h1> </body> </html>

Welcome to the forums Queryeee. I'm glad to see you experimenting with Fieldtypes. Your formatValue() function looks correct. Though you are using it in a different way than I've seen before. So I wanted to pass along some info that I thought might help in the context you are using it. First off, I would suggest that you post your entire Fieldtypetest class, because I want to make sure the other prerequisites are accounted for. Fieldtypes define database schema for a type of field, they identify an Inputfield to handle input, they sleep and wake values for going to/from the database, and they handle sanitization and formatting of their type of values for pages. I want to make sure that your Fieldtype is covering these areas, because it may not work otherwise. When you create a new Fieldtype, you should capitalize the "test" part, like FieldtypeTest rather than Fieldtypetest. When you've successfully created a new Fieldtype module, you have to install it in Admin > Modules. Then you have to create a new field in Admin > Setup > Fields, and choose "test" as your fieldtype. Then you'll add that field to one or more templates, making it apply to any pages using those templates. I'm going to assume you already know all this, but I wanted to mention it just in case. Fieldtypes can optionally specify a formatValue() function to handle runtime formatting. Most fields don't use it, but some do. Examples of fields that use it are text fields where you've added markdown or entity encoding formatters to it. And date fields also use outputFormatting to show formatted dates when it's ON and unix timestamps when it's OFF. The formatValue function is triggered every time you call $page->testField (or any field) and $page->outputFormatting == true. By default, $page->outputFormatting is always TRUE in your web site, so you don't have to think about it unless you need an unformatted value. However, if you are using the API from admin modules or command line scripts, then $page->outputFormatting is FALSE by default. For fields where it matters, you want outputFormatting to be TRUE when you are outputting values for presentation to a web site, but you want it to be FALSE when you are manipulating those values and saving pages. So for those fields, if you try to modify their value on a page when outputFormatting is TRUE, and then try to save the page ($page->save), ProcessWire will throw a fatal error to prevent you from corrupting the data. Why? If it didn't, then you might end up saving values to your page that have runtime formatters applied to them... so the next time you view that page, you'd have double-formatted values, i.e. two <div> tags rather than one, in your case. Luckily, ProcessWire prevents you from doing that. You can set whether outputFormatting is on or off for any page by calling: $page->setOutputFormatting(true or false); If you aren't seeing your <div>...</div> in your $page->testValue, then I'm guessing that $page->outputFormatting is FALSE in the place where you are using it. If you want to confirm, you can do this: echo $page->outputFormatting ? "ON" : "OFF"; However, if you are doing this from one of your site templates, it is going to be ON unless you've specifically turned it off. So if that is the context you are in, then I'm also confused why you aren't seeing your value with the <div></div> between it... and why I think it may be a good idea to post the class file here (or email to me if you prefer). Next, lets look at: $this->config->scripts->add(...) ProcessWire admin uses that a lot so that markup generating modules (Inputfield and Process) can tell it what scripts to load in the admin template. If you look at /wire/templates-admin/default.php, you'll see something like this in the <head> section: <?php foreach($config->styles->unique() as $file) echo "\n\t<link type='text/css' href='$file' rel='stylesheet' />"; foreach($config->scripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> ProcessWire can do this because it's for it's own use, in the admin panel. But it won't make any assumptions about your own templates. It doesn't know or care what you are doing with your own templates, so it's not going to output <script> tags. As a result, if you want to use $config->scripts or $config->styles, then your template will have to do something like the above. And it's perfectly fine to use $config->scripts and $config->styles, that's what they are there for. If you want that script included without your template having to account for it, then I would suggest doing it inline. So your formatValue function would include the <script src='...'></script> tag directly in the returned value, after the </div>. I know that inline scripts are not a best practice in regular markup, but that is in lieu of other factors. if you are trying to build a self-contained Fieldtype that needs to output markup, and you don't want to have to add markup anywhere else, then it would be acceptable to output the <script> tag as part of your value.

Given a PageArray of pages, this module will render an RSS feed from them. This is intended to be used directly from a template file. Installation Download the RSS feed module at the bottom of this message. To install, unzip and place the file in /site/modules/. Go into Admin > Modules and click "Check for new modules" at the bottom. Then click the "install" button for the "MarkupRSS" module. From there, you'll be able to configure several aspects of the module. Usage Create a template in ProcessWire and use the following example as a guide. See the actual .module file for more configuration options too. <?php // retrieve the RSS module $rss = $modules->get("MarkupRSS"); // configure the feed. see the actual module file for more optional config options. $rss->title = "Latest updates"; $rss->description = "The most recent pages updated on my site"; // find the pages you want to appear in the feed. // this can be any group of pages returned by $pages->find() or $page->children(), etc. $items = $pages->find("limit=10, sort=-modified"); // send the output of the RSS feed, and you are done $rss->render($items); This module is now included in the ProcessWire core.

Okay great, glad you resolved it. And also glad it wasn't a forum error.