ryan

I agree with Macrura73 that you don't want to use a repeater for images unless you need more metadata than what the images fieldtype provides. This is also a bit confusing from the code side because 'images' is representing a repeater rather than an images field. But sticking what what you've already got -- based on the examples that you say do work, you should be able to reduce it to this below. I'm also assuming that image_field is set to contain a maximum of 1 image. If not, the code would be a little different. if($page->featured_project->id) { // $page has a featured project $item = $page->featured_project->images->first(); // $item is repeater item if($item->id && $item->image_field) { // there is an item, and it has a populated image field $thumb = $item->image_field->size(100,100); echo "<img src='$thumb->url' alt='$thumb->description' width='$thumb->width' height='$thumb->height' />"; } }

I'm not sure that I totally understand what you are attempting, but I'll pretend I do. With modals and such, you are already relying upon javascript, so it seems like everything else could be accomplished with javascript as well. What you would do is probably link to anchor names in PW, like "#this-item" and "#that-item" or whatever. And those anchor names could match up to <div id='this-item'>...</div>, <div id='that-item'>...</div>, etc. Or you could just look for them to trigger a modal window. Your $(document).ready() function would add click event handlers to any such anchor links. $(document).ready(function() { $("a[href^=#]").click(function() { var anchor = $(this).attr('href'); $(anchor).show(); // or open a modal or something }); });

Joshua, I'd actually like to do a full HTML Kickstart profile for ProcessWire, if that'd be alright with you. Maybe we could collaborate on it sometime?

Sounds like a good idea for a future Inputfield type though.

Looks great Netcarver -- very impressive tool. This is a great list coming together here too.

Thanks I was able to duplicate with the example you posted on one server and not on another. The htaccess file shouldn't send the request on to PW if it contains anything other than "-_.a-z0-9/". But it looks like on some servers, Apache itself doesn't accept the other characters and just removes them, sending the URL on to ProcessWire. The result of something like "/*/" is double slashes, like "//". That's an unexpected condition--we don't expect this from Apache. So I updated ProcessPageView.module to expect it, so that it throws a 404 rather than a fatal 500 error.

Rebooting has fixed more problems in more computers than any other solution ever. I suppose the same could apply to things like restarting APC. I'm guessing that made it clear the cache that was holding it up. But keep an eye out for it. What turns up once might again.

When you say "ID" of an image, is that a number? The reason I ask is because images don't have an ID. They are referenced by their filename, and that is their "ID". So if you are seeing a number when accessing your field, chances are you are really accessing a Page (or repeater item page) rather than an image.

Why not just use $session? Of course, that's represented by a cookie behind the scenes, but the actual data stored in it remains server side and not manipulatable by the user. So it's safer than a cookie from that standpoint. Nearly the only time I use cookies is from Javascript/jQuery, as $session tends to accomplish anything I might use a cookie for on the PHP side.

Since it seems to be specific to the most recent version of both PHP and APC, lets wait it out unless it turns up for more people--maybe there's a bug in APC or PHP. Did you try clearing your APC cache, just in case?

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.