ryan

Some $_SERVER variables like HTTP_REFERER can be manipulated by the client, so it's probably not safe to utilize without sanitization. However, since you are trying to keep track of the last page, I'd suggest using the $session variable. Place this at the top of your page before output: if($session->referrer_id) $page->referrer_page = $pages->get($session->referrer_id); $session->referrer_id = $page->id; Now anytime you want to access the last page, you'd do this: if($page->referrer_page) { echo "Last page you visited was: " echo "<a href='{$page->referrer_page->url}'>{$page->referrer_page->title}</a>"; }

Also take a look at this thread, which is related.

To start, get a fresh copy of ProcessWire and install it (with the included basic profile). Then get a fresh copy of HTML Kickstart and unzip it. You'll want to take these dirs/files from HTML Kickstart (below), and move them to the root of your ProcessWire installation (where ProcessWire's /index.php file is located): /css/ /js/ /style.css I've taken the example.html that comes with KickStart and converted it into starter ProcessWire templates for you: html-kickstart-processwire.zip Unzip the attached file to replace the files in your ProcessWire's /site/templates/ directory. This includes these files: head.inc foot.inc basic-page.php home.php Now view your site. You should see HTML Kickstart's example.html file powering your ProcessWire site. Navigation should be using HTML Kickstart's horizontal menu and both bodycopy and sidebar should populate. I've left several static elements from the HTML Kickstart example.html as well, so you've got more to experiment with here. Let me know how it goes and if it makes sense. This thread is also related.

Definitely use the $pages->count() as Soma mentioned. If you are dealing with a large quantity of pages, and all you need is the count, it is much faster, since it doesn't have to load those pages.

You could accomplish the above in various ways. I'll cover two: Option 1: Structure -people --john ---organization 1, ceo, 2010-2012 ---organization 2, board member, 2009-current --mike --etc. The above would have child pages of each person that represents their organization connections. The fields on that template would be: organization (single page select to /organizations/) position or title (text, their position at the organization) start_year (integer) end_year (integer) Option 2: Repeater This is the option I would use, and it's perfect for this sort of thing. It's basically doing the same thing as option 1, but making it simpler and disconnecting it from the structure. You'd create a new field using ProcessWire's repeater fieldtype, perhaps naming it 'organizations' or 'person_organizations'. Then add the same fields mentioned in the bulleted list above. Add this new 'person_organizations' field to your 'person' template. Now you can define as much meta information for that person<->organization relationship as you want to. More on how to use ProcessWire's Repeater fieldtype

Some great suggestions from the guys above. But the reality is that unless you've got a whole lot of TinyMCE fields, the least time consuming thing to do would just be to edit the fields individually and update for whatever settings you want. Keep a window open with your original copy so you can copy/paste between them. Another thing is that if all these textarea/tinymce fields really do share the same settings, why have so many? Unless they are all being used on the same template, you'd derive more benefit by reusing the same field on all the templates where you need the same TinyMCE settings. Soma is right that it's pretty unusual to have more than 1-3 TinyMCE fields total, even a large site.

The RSS feed module as it is now, is designed to cover the most common scenarios. But it's by no means limited to just common scenarios. Like many things in ProcessWire, it's something that you can copy from /wire/modules/ into /site/modules/ and then modify to cover your specific need. In this case, you'd copy: /wire/modules/Markup/MarkupRSS.module to here: /site/modules/MarkupRSSCustom.module Then edit the /site/modules/MarkupRSSCustom.module file and change this line at the top: class MarkupRSS extends WireData implements Module, ConfigurableModule { To this: class MarkupRSSCustom extends WireData implements Module, ConfigurableModule { And this line: 'title' => 'Markup RSS Feed', to this: 'title' => 'Markup RSS Feed (Customized by Lauri)', Then install the new module from your admin by clicking to: Modules > Check for new modules. Click "Install" for your new Markup RSS Custom module. In your site templates, you will pull in the module using it's new name rather than the old one, i.e. $rss = $modules->get('MarkupRSSCustom'); You can modify your custom RSS module to add any additional fields or capabilities that you want. And you don't have to worry about losing them during ProcessWire upgrades, because everything under /site/ is protected through upgrades. Let me know if you have any questions or need help getting any part of it to work.

If you aren't able to duplicate it yourself, I'd suggest asking them to try a different browser, just in case. Any idea what browser they are currently using?

This is in fact simple to do, but it does require knowing how to put it together without a CMS first. So I would suggest getting your layout up and running as a functional mockup, outside of ProcessWire or any CMS (just HTML and CSS). You could also get by with using an existing HTML page that already does these things. Lets say you've now got that in a file called home.html. With a fresh install of ProcessWire (using the included profile, not the blog one), you'd copy your home.html file to /site/templates/home.php. Now view the homepage on your site. You should see your page. If some things are broken, then that is because the links to the CSS files and other resources have changed. Typically we place our CSS files in /site/templates/styles/ and our javascript files in /site/templates/scripts/. But you can place them wherever you want. Wherever you place them, you'll want to update your /site/templates/home.php file to reference them directly. So if you had a line at the top that said this: <link rel='stylesheet' type='text/css' href='css/style.css' /> Then you'd copy everything from that old 'css' directory into /site/templates/styles/, and then update your code to say this: <link rel='stylesheet' type='text/css' href='/site/templates/styles/style.css' /> Better yet, make it say this, so that it will continue working no matter where you happen to move your site: <link rel='stylesheet' type='text/css' href='<?=$config->urls->templates?>styles/style.css?>' /> With that line above, we're asking ProcessWire's $config variable for the URL to the templates directory. Since it determines that at runtime, it'll work whether your site is running from root or a subdirectory. Once you've got your homepage looking the same as it did outside of ProcessWire, then you are good to move forward with the next step, which is to make it dynamic. This short tutorial will get you started and give you what you need to know to proceed with your magazine style blog homepage. There are also more tutorials in the Wiki that you may want to check out after covering the basics.

We could have a documentation section for this, but the reality is very few people are looking for those items. They aren't part of what one would typically use in developing a site. So we've tried to take the resources we have for processwire.com docs to focus on the more common needs. And then make sure that the less used things (like those you are talking about) are well documented in the code itself, so that you and me, and others digging deeper into the core can find and understand these things when the need comes up. Longer term, as our resources grow, more and more of this will make it into the formal documentation. You can always find a field's type by referencing $field->type. That will always produce an instance of a 'Fieldtype' derivative class. Calling $field->type->className(); will literally tell you which one. You can get an instance of the Inputfield from: $field->getInputfield($page); where $page is the page you want to get the input for. If you don't know what page, then you can just pass it a 'new NullPage()'; Note that calling $field->getInputfield($page); does instantiate the relevant Inputfield module. This means that $config->scripts and $config->styles may be populated with links to scripts/stylesheets used by the Inputfield. Though if you don't specifically use those $config vars, then it doesn't matter.

PayMill looks really nice. Doesn't look like it's available for US customers though.

You are talking about putting that URL in your browser address bar and attempting to load it, right? So far, I can't seem to reproduce that one here. Is it specific to a certain version of ProcessWire? Technically, current versions of ProcessWire shouldn't even receive that request if your htaccess is working properly. What you should get is an Apache 404 (rather than a ProcessWire 404). As a result, I'm going to guess that you are using an older version of PW (2.0?) and that you are either logged in or have debug mode enabled? Let me know if you can think of any other ways to reproduce it? Netcarver, were you able to reproduce it?

When there is a market for it, I'll be glad to have a ProcessWire VIP.

$tax = $pages->find("template=taxonomy, title=1293|1292"); I'm confused about the line above, because the 'title' is numbers like you would usually see as a page ID. Can you confirm that your page titles literally are these numbers? <img src='{$thumb}' alt='$s->description'> The above line should instead be this: <img src='$thumb->url' alt='$thumb->description' />

The ones you are most likely to encounter are translatable from /wire/core/Upload.php There is some other English text in there, but that is mostly for developer use and debugging/testing, so didn't think it needed to be translatable. Though let me know if you find something that should be.

What version of ProcessWire are you running? If it's 2.2.12 or 2.2.13 then this is line 71 of InputfieldPage.module: if(is_string($value) || is_int($value)) { In terms of environment, mine is very similar to yours, but slightly older: PHP 5.4.4 and APC 3.1.9.

Good idea for sure--thanks. Can't say as though I've ever created field names that long, so never encountered this issue. But of course we should be accounting for this. I will fix!

Try to make your columns to add up to 100% if possible. 15x6 = 90. 15x7=105. 16x6=96. 16% would get you closer to 100%. You could use 16% instead and make the first or last four in the column 17%. As for why they would be behaving differently in two different instances, that's a good question, and I'm not sure about that. It's the same code that executes regardless of output, so that's a mystery. I will have to give it a try. What are the two scenarios where you are doing this so I can reproduce most accurately?

Yes this would totally replace the ProcessPageAdd, so it would be using yours every time you clicked "new". Of course, you can make your ProcessPageAddDoolak do anything, perform any additional checks, etc.

It sounds like you've got a good idea here, but I'm not sure that I understand? Are you talking about identifying what delegate inputfield class a Page inputfield uses? The ones you mentioned (checkboxes, radios, asmselect, etc.) fit that description. But I'm not clear about why you want to retrieve that or where you are showing it. It could also be that it's the end of the work day here and all my caffeine has long worn off. I might need to come back to this and read again in the morning.

In this case I think it's because the Inputfield keeps a copy of the parent ID rather than an instance of the page. The term 'parent' already has another meaning with Inputfields as one Inputfield can be a parent of another (like a Fieldset being a parent of a Text field, or the like).

ProcessWire will do all of this, but Pete is right that you'd have to do it from the API side rather than click to setup. Probably what I will do is build some more formal workflow modules in upcoming versions of PW that do it out of the box but also give you a good starting point to modify from. Currently it's fairly trivial in ProcessWire to setup a workflow for approval of new pages to be published. But setting up the workflow for approval of modifications to already-published pages takes much more on the API code side.

Nick--Thanks for using FormBuilder. I've updated your access so you can now see the Form Builder board. See this guide in the Form Builder board which may answer some of your questions, or let me know if you have any questions.

Thanks--It looks like there are two issues there I missed. I will take a closer look and attempt to fix these tomorrow morning.

Another approach you might take is to copy ProcessPageAdd.module to /site/modules/ProcessPageAddDoolak.module. Edit the file, and rename the class to be the same too. Then go to Modules > Check for new modules, and add your version of it. Go and edit the 'Add' page (Which is here: Admin > Page > Add). Change the 'Process' field from ProcessPageAdd to ProcessPageAddDoolak. Now you have full control over the page adding process.