Leaderboard

Hi Grays, welcome to the forum. Even though I have been playing with PW for a couple months now, I too am still very green and new to it. I was in the same boat as you and still am trying to grasp the basics, but take the advice of everyone else above. The people here on the forums are very helpful and friendly. Don't be afraid to ask questions. There are a lot of smart peeps here and I find this is one of the most friendliest, most responsive CMS forums of them all. Make friends with other newbies (such as myself) and follow the questions they ask. Seach the forums for the ones asking basic questions and those will more likely be the newbies. I think for me, the best thing I could do was to take it slow and lower my expectations. I fell in love with PW right off the bat and wanted to be a a pro in it. But, even though I had read a few PHP books and took some courses beforehand, in reality I was lost and dissapointed. It's more a mental/confidence thing with me, but once I accepted the fact that it was going to take some time, and I wasn't going to be an immediate whiz, things got easier. So. I started off (still am) doing the basics, one thing at a time. Break up your site into smaller parts and work on each one by one. When you get something simple working, your pride will fuel the next challenge and before you know it, you'll be at the top. Analyze the code here in the forums and don't just copy/paste. Try to really understand it by cross checking with how PHP works. A great thread started not long ago on learning PHP is here. You may not understand it in one try, I know I didn't. Sometimes it takes days or weeks for something to "click" in your head. Read, re-read, read again. Things DO get easier but it takes time, and time is the secret. Practice helps. It's inspiring what you can do with PW and what keeps me going is knowing this is the best CMS out there. I have researched and tried almost all of them over the years, but nothing compares to PW. I am inspired every day to continue learning and not giving up because it's absolutely worth it. MY breakdown to how I am learning: Take it slow. Break code examples down line by line. Moving on to the next line only after knowing what each before it does. You'll get it! Don't attempt something expecting results the first time. Take pride in humiliation. You can only learn after making mistakes. Read this PW wiki Study Codecademy PHP course along with a couple PHP books. Try to go through every forum completly. Go through each page one by one, bookmarking where you left off. I do this before I go to bed. Before you know it, you'll have read all the forum topics and can know be updated when new threads post. ask questions. I know this can be kinda hard because you don't want to look like an "insert insult", but the truth of the matter is if everyone is afraid to ask then it's hard for newbies like you and I to find answers to basic questions. It's a win win for everyone and the CMS itself. breaking down basic elements of a site one section at a time and searching the forums for how to do it (navigation, multi-level navigation, photo gallery, forms, etc..) You may have to read multiple threads but it's all there. Good luck and don't give up! I can never look back at any other CMS, even during times when I'm frustrated or lost! I only get frustrated with PW because I do not know YET how to proficient. I was frustrated USING other CMS's because of how they were built and I knew their code. Says a lot right there.

grab.pw should definitely always point to a zip of the latest stable release. wget http://grab.pw

Since these comments might give impression that Fredi is just page editing in a modal (like AdminBar does) I just wanted to mention that the main difference (and the only reason I wrote this module), is you can use Fredi per field basis. That means you can build super nice front end editing UI, where you have edit icons just next to the content you want to edit. When you have over 10 fields per page it might be confusing for users trying to figure out where content is shown. Seeing clients used AdminBar never made me happy - with big templates they were just lost and it would have been nicer to just send them to actual admin page. That being said - modules like Fredi really makes the line between content and visuals more unclear and are not a great fit for all sites. And while "field at the time" was the main driver, I can see the benefit for having full page edit modals also (although if template has 13 fields, I would cut that to three or five edit links, based on how the layout works in frontend). $fredi->renderAll() is now implemented - currently it also allows deleting and creating child pages (not sure if I like that).

There was a thread elsewhere concerning some type of showcase for ProcessWire sites. I found the following in my G+ feed today

Greetings, Glad to see this discussion, because I need this for a couple of projects as well. I've been playing with a couple of ways to do this, which I describe below in plain (non-code) language. There are two parts here, each with their own solutions. As Ryan explained, these ideas require creating and editing pages via the API: 1. Approval to Publish I am currently handling this is by adding a simple "published" checkbox that is only visible to people with certain rights. When searching for pages to display, I only find those that are approved (checkbox = "1"). 2. Approval to Edit For this, I think ceberlin and I are fairly close. First, we need to use the API to create an edit page for our content. Inside that edit page, there are two forms: the "live" form, which contains the currently published material; and an "edit" form, whose fields simply repeat those in the "live" form. Initially, the values in each form are identical. When someone without enough rights changes the "edit" form and hits "submit," the page then contains different information in the "edit" form and the "live" form. But the "live" form continues to be the currently published material. When someone with higher rights visits the edit page, and submits changes in the "edit" form, the changes overwrite the "live" form and that is what now appears in the live site. In this case, the page is saved using the values in the "edit" form using the normal page-creation/page-editing routines of the API. How does this sound? Thanks, Matthew EDIT: A couple of things I forgot to mention above... First, the "edit" form should be the way that everyone submits changes, no matter what your approval rights are. The difference is, people without approval rights would only see a "Submit Draft" button (only changes the "edit" form), but people with higher approval rights see a "Submit Draft" and a "Publish Changes" button. Next, we need to handle the initial pre-population of the "edit" form. There would be logic in the edit page to detect if the "live" and "edit" forms have the same data, or if they have different data. If they are different, we don't want the "edit" form to be overwritten. That way, proposed changes are preserved until approval is made. When the "Publish Changes" button is clicked, it would overrwite both the "live" and "edit" form fields. If the "Submit Draft" button is clicked, only the "edit" form is changed. This allows edits to be "discussed" until approval is made.

I've tagged and released version 1.0.4 with various minor improvements and fixes. NOTE: uninstall 1.0.3 before upgrading! It looks like dependency on the new icon-selector causes breakage if you simply drop in the new files.

Your service provider probably already has set these parameters. They are not allowing you to override them. Normally you would not want indexes displayed in application folders or on a normal site, Which is why you you see empty index.html files in directories in some applications or the -Indexes directive in your .htaccess file. You can test for this condition by going to a folder without a directory index file, that has other resources. If you don't see anything then indexing is not on in for that host (or implicitly set on that dir) I am pretty sure Processwire is not using symbolic links. It is possible that someone could or did write a module that does. Just none that I am aware of. If you create some yourself, you won't be able to follow them in, Apache if this directive is not enabled. I know that drupal does need this directive for a private download method in the core. Not sure why it is present in the PW .htaccess file. From the Apache Docs.. Indexes If a URL which maps to a directory is requested, and there is no DirectoryIndex (e.g., index.html) in that directory, then mod_autoindex will return a formatted listing of the directory. FollowSymLinks The server will follow symbolic links in this directory. http://httpd.apache.org/docs/2.2/mod/core.html#options

@k07n: The module looks good. But start your class with an uppercase character, otherwise it might confuse PW's module parser, which is expecting it for categorization purposes. @jmart: 301 would really be the right way to do it and would not be a nightmare. Use Apeisa's redirects module and life will be easy. But if you really need all pages to be accessible at root level (which is not something I'd recommend) you could accomplish it by editing your 'home' template, clicking to the 'URLs' tab and enabling URL segments. Then in your home.php template: if($input->urlSegment1) { $p = $pages->find("name=" . $sanitizer->pageName($input->urlSegment1))->first(); if($p) { $session->redirect($p->url); // 301 redirect to it // echo $p->render(); // or output it here, no redirect } else { throw new Wire404Exception(); } } else { // render homepage }

Thanks for letting us know. That's cheap enough to make me jump. Already had a namecheap account, so went ahead and registered a few that were still available: runs.pw (maybe a sites directory?) grab.pw (fwd to the github maybe?) mods.pw (fwd for the modules dir) processwire.pw (why not) skyscrapers.pw (for the demo site) skyscraper.pw (for the demo site) wires.pw (who knows?) Anyone else find or buy any good ones?

One of the ways you can show support for ProcessWire is to help get the word out by including a small "Powered by ProcessWire CMS" tagline (ideally linking to processwire.com) in the footer of sites that you develop. This is a big help to the ProcessWire project. But I know there are many cases where it just doesn't work to do that because the client thinks of it as gratuitous. I think it's important to communicate to your client that it's not gratuitous at all. It is doing the right thing by showing appreciation and support for a software that is running their site at no cost. Even so, it's not always as simple as that, and I completely understand. We have no requirement or expectation that sites developed in ProcessWire do this. We just encourage and appreciate it when you can. Let your client decide One thing I've been doing lately is to put the control into my clients hands. They really appreciate that I've given them control over it… more so than if I'd left out mention of ProcessWire completely. It also makes them feel good as they are the one showing support, not just their site developer. Here's how to do it in 1 minute: 1. Create a new "checkbox" field in Setup > Fields called "toggle_powered" (or whatever you want to call it), and enter the following for label and description: 2. Add the "toggle_powered" field to your homepage template. 3. Edit the homepage and check the box (if possible in your situation). 4. Edit the template file or include file that contains the site footer and paste in the following: <?php if($pages->get('/')->toggle_powered): ?> <p> <a id='processwire' target='_blank' href='http://processwire.com'>Powered by ProcessWire Open Source CMS/CMF</a> </p> <?php endif; ?> The code above is an example, so adjust the markup, size, wording and placement to suit the site.

Ah, ok! I got it now

Thanks Luis. - so have to say: I only want put together the basic stuff but also want to keep it modular and scalable. For example I personally only use mp3-files but if people use other formats like ogg they should be able to extend the class module for that easily. Maybe with some help it could become really nice and not only poor basic ;-) If someone has good skills on how to build / design / layout admin pages with that UI-stuff it would be really helpful if he/she could design the output for the backend. Also if someone is good with frontend design and want to collaborate that would be great too. I have a really short screencast of what I have done till now, (most of this was learning how to send green or red messages to admin screen, how / where to store config data, to create permissions and roles, and basically how to create a module that has a page in the admin section, ...): https://youtu.be/u_S8ajLkzRI Next steps are to parse ID3Tags, compare file-data with DB-data and import new tracks. Question: is it possible to store arrays or WireData on a page?

The find method only accepts the pw selectors. What you are doing there seems very different to me to what Soma did in that example. The way Soma concatenated that string I can see that it will be something like this (just guessing, i didn't look at his code); // $selector = any selector f.ex. "template=basic-page," // $_REQUEST['iDisplayStart'] = 10 // $_REQUEST['iDisplayLength'] = 20 $pa = $this->pages->find("template=basic-page, start=10, limit=20"); which is a valid selector. In your selector the result of the concatenation would be something like this, right?: $values = $pages->find("parent=/LIMIT0,15"); // ?? You can't use regular mySQL queries because they won't be recognized by the method. If you want to use queries you can use query() http://processwire.com/talk/topic/2209-display-data-from-mysql-table/?p=20630

Hi All, Thanks for your tips. It got my brain working again and I (gasp) *Googled* for the answer. Which I should have done in the beginning. Google is our friend. Well, sort of. I found this tinyMCE directive, added it, and it worked like a charm: apply_source_formatting:true Thanks! Peter

Hi Antti, Sorry if those comments seemed unappreciative. I completely see the value of being able to edit single fields separately on a page. Perhaps the idea of RenderAll doesn't really fit well with this module. Personally, the biggest benefit for me with Fredi is the ability to edit content from other pages - this is where AdminBar lets me down. I guess I am thinking of a way to combine the best of both somehow. I'll let you know if I have any brilliant ideas

Hi Soma, that's perfect for this needs, as I allready create a page for the module, I now also create a childpage for the config data. I have to learn to think less complicated when working with PW! I also have created 2 permissions and 2 roles to have access control. It tooks only 5 minutes for this! (Das ist so geil!) If I have not allready said it: I love ProcessWire!

@Soma: A tiny typo in your verb, change cab to can.

You can read more about output formatting about half way down this page: http://processwire.com/api/variables/page/ But, in your particular situation, Soma explains it well here: http://processwire.com/talk/topic/2917-command-line-script-file-api-not-performing-same-as-on-website/?p=28697 "Image field is always an array, it's just that page output formatting does change it so in template files you get an object if the image field is set to max 1 item. So if output formatting is off it's always treated as an array, disregarding the field settings." If you have it set to false, or you have max images set to anything but '1' then you need to do one of the following: $page->column1_image->first()->url $page->column1_image->eq(3)->url $page->column1_image->last()->url

Field label is not in the page field value, you have to get it through the field itself. echo $fields->get("body")->label;

Sorry that doesn't work. Does your original: $out .="<span>Price: </span><span>{$product->product_price}</span>"; print out the price correctly? Might be a silly question - but does your product_price field definitely have a Label defined? I checked the $product->fields->product_price->label and it works well for me. Just to be sure, can you try: $product->fields->product_price->name instead? number_format should work like that, but maybe just to test any issues with $product->product_price, try testing with something simply like "round" I see Soma lurking here too, so maybe he'll chime in

I've been making regular updates on the dev branch to the LanguageSupportPageNames module, so if you guys are using this, you may want to keep track of the updates. The good news is that this module is now running a production site: http://tripsite.com/cruises/ (only the /cruises/ site, as the rest of the site is running on a different copy of PW). This morning I pushed an update that makes it easier to tell if a given $page is viewable in another language. Now you can do this: if($page->viewable($language)) { ... } // Language object if($page->viewable('es')) { ... } // Language name That is basically telling you if the page has its "active" checkbox checked. Since these pages would already be excluded from search results, you don't typically need to use it except when on a given page and trying to determine what other languages that page is available in (like if you want to link to them, as the select box at the top of tripsite does).

I registered selector.pw a while back. I've got an idea of some kind, but we'll see if I'm ever able to get anything up and running there...

We have it build in. Thanks Ryan.

What are you missing again? Paths prefixes? you mean like /de/... /en/... ? Those are set on the homepage name.

I'd strongly recommend reading the follow up by MODX Co-founder Ryan (T), posted last night: http://modx.com/blog/2013/04/10/putting-the-band-back-together/ SiphonLabs is not MODX, but it is the Cloud team being flushed away from MODX. And that has the side effect of liberating the MODX team to focus once again on what matters: building MODX. While I can fully understand that there's confusion and people wondering what on earth is going on, this change isn't new - it was put in motion in early January. In that time, Ryan (T) has been working incredibly hard to give MODX a fresh start and making things happen that need to happen.

What any newbie should do first is learn Drupal. After 2 years of: awful theming, i.e. $element['#object']->field_video_embed['und'][0]['value'] instead of $page->field_video_embed searching through 500 line arrays to find out what module is injecting a certain markup in your code writing huge css files to deal with the divs nested within divs nested within divs nested within divs figuring out how to add a meta tag to your <head> using an API and an array getting carpal tunnel syndrome from constantly clearing the cache because Drupal is such a hog, everything has to be cached learning the Views module, a point and click interface that is 3X more annoying and difficult than learning and using straight SQL find a good host that is beefy enough to deal with the Drupal and has advanced caching capability After that, PW will be a walk in the park.

I just posted an update to the LanguageSupportPageNames module that appears in the 2.3 dev branch. The screenshot explains it best: Basically, you can uncheck the "active" box for any language, and that page becomes unpublished, for that language only. It behaves the same way as an unpublished page, in that it doesn't show up in searches, and produces a 404 if you try to view it (unless it's editable, in which case you can still see it). You don't see a checkbox next to the default language, because that one is controlled the same way as before (via the page's unpublished status).

Maybe the default templates could be an optional part of the setup process. Perhaps an advanced options area to turn off their creation?

First there was an object. It was so lonely and had no home so we gave him an url. It was very happy and lived long until someone came and deleted it.

why.not just make custom tamplate for 404 page?

Pages will definitely scale quite far. But there is certainly more overhead with a page than there is with a plain DB table. As a result, when you are talking about storing huge quantities of data, I would keep your pages to represent the visible URLs on your site. If each row of data isn't going to be related to a unique URL in your page structure, then there really isn't a technical need to store it as a page. Though if you don't need infinite scalability, you may still find using pages for that data to be more convenient. But since it sounds like you do need near-infinite scalability, going to the DB sounds like a better choice. ProcessWire Fieldtypes are designed to represent simple and complex structures in this way, while still letting you use the API admin interface to handle it all. However this does require developing your own Fieldtype and Inputfield to manage it (which actually isn't too difficult). If you don't need an interface and/or PW API access to manage it, you can also just go straight to the $db object as if ProcessWire wasn't there. But this isn't as nice or fun as having your data still be connected with ProcessWire.

You just create fieldsets and use width column option. The trick then is to hide the fieldset label via css. Ive done it myself with teflon theme and will soon update it with same approach and also made the field labels white to remove cluttr.

Doesn't look like I will get the time for at least a few weeks, but what I had in mind for making an awesome newsletter module for ProcessWire is things like this: Building templates in PW's template system (duh) Being able to reference content from elsewhere on the site (like check out X amazin product/service) - essentially a repeater field for Service Title (if you want to override the page title you're referencing) short description (again, only if you want to override that page's summary), image from that page and then being able to drag and drop that sort of content quickly into any order. And so on It's really exciting when you think about all the possibilities of what you can do just by creating each newsletter content as a normal page and template combination, so I think that any such module should leave that completely separate and just focus on: Subscribes/unsubscribes - a default system to store subscribers as users with a guest and newsletter role (I think it should be this anyway) and make the class so it can easily be extended to add/remove/deal with subscribers any other way someone can think of Sending mail Dealing with bounces (from systems like Mandrill, although if you read the info it deals with a lot of this itself if you forget to remove bad addresses - it just won't send to them again to keep you compliant and will notify you, which is nice) These are the basics and I think it could just be a case of keeping it this basic - everything else is a case of PW pages and templates then, plus a bit of a headache in terms of making all your styles inline once again like back when you didn't know what a stylesheet was For that reason alone, perhaps it should ship with a default page, some fields and a template as an example? It could well be that this is complex enough to warrant another paid module, especially when you start thinking about shipping it with a selection of templates, or considering ways to make it easy to download new templates from within the module (probably a version 2 feature!).

If you wanted all grandchildren, and nothing deeper, you could do this: $page->find("parent=$page->children"); If you wanted grandchildren and anything deeper, you could do this: $page->find("parent!=$page"); If you wanted children, grandchildren and anything deeper, you could do this: $page->find('');

Use your title field for the term, and another field for the definition. For the parent of all these terms, set the default sort to be by 'title' on it's children tab. Then you'd code it something like this (below). I'll use a <dl> rather than a <ul> since a <dl> would be more semantically correct here. <?php function listDefinitions(PageArray $children) { $out = ''; $lastLetter = ''; foreach($children as $p) { $letter = strtoupper(substr($p->title, 0, 1)); if($letter != $lastLetter) { if($out) $out .= "</dl>"; $out .= "<h3>$letter</h3><dl>"; $lastLetter = $letter; } $out .= "<dt>{$p->title}</dt><dd>{$p->definition}</dd>"; } if($out) $out .= "</dl>"; return $out; } echo listDefinitions($page->children);