Leaderboard

Feasibly it's possible, but it's not desirable. Making wire('var') aware of context involves pre-compiling the template files to replace wire('var') with wire($this, 'var'). So it's something we do to provide backwards compatibility in template files. We won't be providing that backwards compatibility outside of template files, so people will have to use $this->var, $this->wire('var') or wire($this, 'var'); elsewhere. Also, a Static::syntax implies dealing with a framework that only has one context, which gives the appearance of a weakness that isn't there, something I think we'd want to avoid. While I'd really like to limit statics in ProcessWire as much as possible (just because they are more than often a bad programming practice), that syntax is perfectly fine for static functions where context doesn't matter or where you are passing the context into it. For example, $sanitizer functions would not need to have different behavior in different contexts. I've even seen some frameworks that do use statics for sanitization functions as well. In the end though, IMO they would still be better served by providing the same functions non-statically. The plan is that when you do this... $main = new ProcessWire('/site/'); $intranet = new ProcessWire('/site-intranet/'); ...everything in each of those two instances will be unique to those instances and whatever site files are stored in /site/ or /site-intranet/. That means that when a module is initialized, it is only initialized for the instance (whether main or intranet). When a module refers to $this->var, it's referring to API variables that are part of its instance only. This enables you to have multiple sites talking to each other. Currently this isn't possible precisely because PW uses statics for API variables behind the scenes. But the fact that we've kept that behind the scenes is a good thing because that means it doesn't matter how our API variables are stored. We can switch them to a stronger storage mechanism that would be tied to an instance. This is one reason why I deprecated the Wire::getFuel() syntax (that appeared in early versions of PW2) early-on... though you might still see it appear in a few core spots, which will need to be changed. But we've really tried to keep the public API clear of static calls so that the API would not have to change as PW continues to grow as a framework.

HI, I'm looking to implement some rules for password creation and I imagine I'll need to create a module for this. One thing I'd like to do is block the 10,000 most common passwords (From this article) by checking the entered password against the file containing the list. Are there any methods of hooking into the password reset page (or potentially any password entry pages I need to create) to validate against the list or will this require more than a module to accomplish? EDIT: Title is misleading, it should have been password validation rather than password entry. Apologies.

My solution would be: 1. create a new field called "use_wysiwyg" and choose "checkbox" as type 2. create a field "body_raw" or whatever you want to call the body field without wysiwyg 3. Add both fields to your template and save it Now let the processwire magic play: 4. Now click on "body" And go to Visibility -> Show this field only if... and add the following: 5. Do the same thing with "body_raw". Only difference: "use_wysiwyg=0" Now the wysiwyg editor should only appear if the checkbox is checked. In your template do this to get the content: $page->get('body|body_raw');

As a basic test case, you could add this to your /site/templates/admin.php wire()->addHookAfter('InputfieldPassword::processInput', function($event) { $inputfield = $event->object; $password = $inputfield->attr('value'); $bad = array('test', 'abc', '123', 'password', 'unicorn'); if(in_array($password, $bad)) { $inputfield->error("That's not good enough of a password, try again"); $inputfield->attr('value', ''); } });

Hey people, look LOOK LOOOOOK at the latest commit on dev https://github.com/ryancramerdesign/ProcessWire/commit/36ec37d171672a1b786a554539cb5123b09117bc InputfieldPageTable now supports multiple templates for child items, so this is (at least for me) solving this issue. Hack away with you flexible page designs! :biggrin: CHEERS

@nico - good solution, only issue is what if the editor enters some stuff in the wysiwyg, and then later decides to switch to raw; the pipe wouldn't work right, so maybe instead use the checkbox to determine which to show on output? echo $page->use_wysiwyg==0 ? $page->body_raw : $page->body;

Well, this could be done. But ProcessWire doesn't work with common language strings. If a developer codes a module all he has to do for being translation-ready is to put something like __('this is my string I want to translate') in his code. This is very handy because you don't deal with cryptic language variables. The downside is, you (or someone) has to use the language translation module to point to the file with the translation but then has a very comfortable way of translating it. Once a language file is translated a json is generated which can be used by everyone. The problem is, this file is located somewhere in the file system (look at the url while translating, identify the id, look in site/assets/files/id where you find all the translation files). I think what we (and Ryan) could do is to encourage module developers to create an (even empty) language file and ship that with a module (like ModuleName/lang/en/site--modules--ModuleName-module.json. So the only thing you have to do is to upload this/these json file(s) to your language and translate it. After that you could do a pull request to the project, so it could be easily integrated for others. Another problem is that these language jsons are named by the module path. And if not installed by ModuleManager, everyone can at least name the folder differently. But providing (even empty) jsons would be a good start I think.

PDF Fieldtype/Inputfield Module for ProcessWire allowing you to easily generate thumbnails of the PDF files embedded to the site. Current version: 1.1.2 (Changelog) Module page: http://modules.processwire.com/modules/fieldtype-pdf Github: https://github.com/uiii/ProcessWire-FieldtypePDF For detailed instructions see: https://github.com/uiii/ProcessWire-FieldtypePDF/blob/master/README.md

@kongondo the functionality was added a little while back and is already in the stable 2.4.0. See these four hooks in Pages.php.

I'm using RSS on my site like this: 1. Create a template "feed" or "rss" 2. Create a hidden page ("/feed/" or "/rss/" or whatever you want your url to be) 3. Uploading and customize the following file into template directory and update the field names feed.php

I think based on the number of likes Willy's comments get that he's well liked

If you've done heavy frontend WordPress development, then you may have heard of Roots: http://roots.io/ Roots 7.0.0 on Github: https://github.com/roots/roots/tree/7.0.0 It's described as: Roots, a WordPress starter theme, helps you make better themes with HTML5 Boilerplate, Bootstrap, and Grunt. Some key points from their site: Optimized for production use - The Roots Gruntfile compiles your LESS & minifies and concatenates CSS and JS. Bootstrap ready - Roots includes Bootstrap for faster web development, but it can easily be removed or replaced with your preferred CSS framework. Write less code with the theme wrapper - Template markup is controlled by a theme wrapper and is handled by one file instead of being scattered across all template files like typical themes. It's a starter theme (not a theme with an existing design) for tech savy developers and comes pre-configured with a nice set of tools, build scripts (css and js minification, etc) and an excellent template architecture and file organization from which you can build a site. How everything is organized is what makes it shine (as well as how it fixes a lot of ugly things in WordPress). I've been using it as my go to starter theme for over a year and I like the way it's been thought out. I recently used it on a large corporate site with some strict production environment requirements and it allowed me to dive very deep into Roots and get a great understanding of it. With that being said, I still have yet to settle on a standard site profile for when I create ProcessWire-based websites. I figured since I like Roots so much, I could create a site profile based off of it, if not for the template structure, then mainly for the tools it provides as well as file organization. I spent a couple hours and got a lot completed already. Anyone else have experience with Roots? Jonathan

Hi Tyssen, regarding the likes module. I've recently implemented a liking system that isn't as yet moduralised but that works well. I'd be happy to point you in the right direction.

Hi bytesource, thank you for your question. As you can find in ProcessImageMinimize's documentation, the module is using a workflow internally to asynchronously pass and fetch the images to and from our servers. With ProCache enabled, your site is basically cached as static files on your server, so no PHP scripts will be executed - which leads to ProcessImageMinimize not being executed. To cut a long story short, we are currently recommending you to turn off ProCache for one site so that ProcessImageMinimize is able to work. We are currently working on a solution for this, so stay tuned.

The gui way could be the maps module by Ryan. Make a page per location, and then you can pull the coordinates from every page and add them all to the footer map with the maps api. There are some Jquery plugins that make it easier to work with the api. Gmaps.js is a good option http://hpneo.github.io/gmaps/

Hi qlex and welcome to PW - hopefully you'll stick around after this client request Here are the instructions for using the RSS module: http://modules.processwire.com/modules/markup-rss/ Also, you may want to consider this enhanced version of the RSS module: http://modules.processwire.com/modules/markup-rssenhanced/ Let us know if you need any specific help getting things to work.

I very frequently see people not finding stuff in the forums, I don't blame them, the forum search sucks bit time Then many times forum members suggest to use {searchterm} site:processwire.com/talk on Google. It's true, nine times out of ten I DON'T find what I am looking for using the standard forum search. Nine times out of ten I DO find what I am looking for using Google search. So perhaps there should be a hint on the search dialog/page to use Google instead (if that's even possible). New users would find stuff quicker, saves time for all.

Hi, you need to go and read how to call thumbnails with the Thumbnails Module. It is explained on the Modulespage. SOmething like $cropfield->getThumb('nameOfYourThumbsetting') In the above code you simply request a Pageimage of 100 x 100 (centered autocropping)

If it's not working from inside site/assets, then I think there must be something else at play. I actually just tested locally and I can even download: http://pwtest.dev/assets/form-downloads/11 AHAA SPRING DISTRICT MEETING FORM.doc just fine, and looking at PW's htaccess there is a rule for ignoring folders when rewriting so it should work and it does - my mistake above. EDIT: I see that: http://ahaa.inthooz.me/assets/img/ahaa-header-logo.png works fine on your site, so can you narrow it down to the form-downloads folder or the mixed case/space ridden filenames? Have you switched servers? Do the cases of the filenames in the links actually match the filenames? ie Windows vs Linux issue? ANOTHER EDIT: It is weird to me that the page you are getting when trying to download is actually the homepage with a 404 header and not the actual 404 page. AND ANOTHER: Notice that: http://ahaa.inthooz.me/site/assets/form-downloads/dd.doc'>http://ahaa.inthooz.me/site/assets/form-downloads/dd.doc gives you a proper 404 page, but: http://ahaa.inthooz.me/site/assets/form-downloads/d d.doc takes you to the homepage with a 404 header. Turns out I get the same thing locally!

The first thing I notice is the spaces and mixed case in the filenames. This is a bad idea for lots of reasons which is why if you uploaded the docs via a Files field in PW it would have converted them for you. I think what is causing the 404 is PW's htaccess rewrites. It sees: http://ahaa.inthooz.me/assets/form-downloads/ and goes looking for a page with that path. You could potentially move form-downloads into: http://ahaa.inthooz.me/site/assets/form-downloads/ and things should work just fine. But, why not upload them to PW and have files that are part of the system? EDIT: having them all in a files field in PW means you could use this code to provide download links to all and it would automatically work for all new files as they are added: echo "<ul>"; foreach($page->files as $file){ echo "For the {$file->description} form, <a href='{$file->url}'>click here!</a>"; } echo "</ul>"; Although personally I hate "click here" links, but I went with how you had things structured already

@everfreecreative Have you ever used the Thumbnails module for customizing cropped thumbnails for your gallery images? Any tips for doing so? Ultimately I would like to have the full collection of gallery thumbnails set to a specific square size. I would also like to present the index gallery thumbnails (that point to the actual child galleries) at a different larger thumbnail size... Thanks!

@zyON: at that point the original name, one without "pageid_" prefix, is nowhere to be found. Hence you actually need to strip the prefix to get the original name. Take a look at how ProcessWire itself does this when restoring pages from trash: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Pages.php#L1006.

You could install it in /wire/modules/ rather than /site/modules/. However, I don't recommend doing that because it'll get overwritten every time you upgrade the core, which would be a bigger problem than having multiple copies of it. Use symbolic links instead (for /site/modules/ProCache/) and you'll only have to keep one copy of the ProCache files.

I've updated the module. Added requirements check and ImageMagick settings.

There ara probably many different ways to achieve the result (nice solution though)... It's just a matter of convenience.

Macrura, If you look at the DB table for the PageTable field you'll see how the data column lists the page ids that are included as items in the PageTable. I think you should just have to add rows for each of the pages you want included for editing in the page table. I was actually thinking this morning about this - currently it is possible for someone to add a new child page manually, but these won't appear in the PageTable field for editing. I wonder if there needs to be a way to prevent this as it could get confusing. Another issue for PageTable fields in my mind - if you use the default page as the parent for storing the entry child pages, but you also have regular child pages mixed in, it may become quite confusing for editors. I guess this comes down to the dev being careful about choosing a different parent in cases where there might be confusion. Did that make sense?

Missing an =? ($page->use_wysiwyg==0)

Maybe you could add a "check for new translations" button to the language settings. This button would glob() recursively through the modules folder and collect all of the language files. These files should follow a conviction like "ProcessProgress.de.lang.json" or have some kind of install information in it to let the crawler recognize to which language the files belong.

Even if it's unlikely to become a problem here, judging from your use case, I'd like to point out that in addition to this general limit for displaying maps via maps API there are separate limits for things like using the geocoding API - in this case it's 2500 requests each day. MapMarker module, by default, sends new requests to geocoding API each time you move a pin on a map or type in a new address and convert that to coordinates. If your site has a lot of content managers, this limit is surprisingly easy to hit (For one site with a few hundred content managers managing a bunch of maps each I'm running a modified version of the module with an extra option for shutting all these requests down from field settings.. there are still quite a few benefits for the field type itself.)

Well, you could use: http://modules.processwire.com/modules/fieldtype-map-marker/ but I wonder if the Google static maps API might be better if it is in the footer of every page: https://developers.google.com/maps/documentation/staticmaps/?csw=1 There is a limit of 25000 hits per day, so if you'll be inside that, it's a decent option. The only catch with the static option is providing a GUI way for users to add markers. There are other options out there too, but let us know if you think either of those will work.

Hi Ryan, Will you be getting round to this any time soon? I currently would like this functionality for this issue in 'Blog'...otherwise I would have to possibly create an autoload module as shown here. Thanks.

Uups, have copied the latest version over my previous installed one, where a file of Diagnose Modules exists but is not installed! After login, when trying to go to the Modules-Tab of the Backend, I get this: Fatal error: Can't use method return value in write context in DOC_ROOT\site\modules\ProcessDiagnostics\DiagnoseModules.module on line 102 Makes my Modules Backend unusable (PW 2.4.2) - Haven't investigated further. @Nico: Do you need more infos? ----------- DiagnoseDatabase module works fine! I have some of these Warnings: 'Repair table to reclaim space.' What's about a Button that lets the user directly execute an optimize / repair? $query = 'OPTIMIZE NO_WRITE_TO_BINLOG TABLE ' . implode(', ', $tableNames);

Regarding your enddate not saving, there are a couple of things going on. InputfieldCourses.module: Change: $course->dateend = $dateend; to: $course->dateend = $input->{"{$name}_dateend"}[$cnt]; Course.php Change: } else if($key == 'date') { to: } else if($key == 'date' || $key == 'dateend') { That will get your dateend field saving on creation. However, the one thing I just noticed is that you can't make any changes to the course once it is saved. I haven't investigated this yet, but did you notice that also? EDIT: Also those checkboxes are going to have issues - you need to a checked="checked" in each input based on whether there is a 1 in the database or not, but you'll also need to take care of assigning that "1". Now for why changes are not saving - I am still not sure exactly why and have run out of time, but a quick and dirty fix is to comment out this line in InputfieldCourse.module: if("$courses" != "$this->value" || $numDeleted) { I don't really know why $courses and $this->value are not being set appropriately, but they are both set to "Course" which obviously isn't much use. Hope that all helps a bit.

Oh, also something to think about – I don't know how you guys handle this, and it obviously depends very much on the project and the modules used. I think translations are (mostly) for users, e.g. editors. Admins should be able to handle a PW backend in English, although I wouldn't call it a requirement. However, I wouldn't know how someone who doesn't read English would even be able to understand PW enough to administrate a PW installation. Most of the documentation is in English only. So in most of my projects, clients have a “backup” admin account, but use PW as editors, which means they don't get to see much more than the page tree, which is a core feature. What I'm trying to say is maybe we're overthinking modules translations quite a bit here. Yes, they would be nice to have, yes, it would be nice to have a way to easily install them. But if someone definitely wants a module's backend section translated, a bit of work to install the translation should be fine.

Can, not directly answering your situation, but have you seen the ProFields and the Table fieldtype there? If not, take a look: https://processwire.com/talk/store/product/10-profields/ Also PageTable field that ships with core (available on dev branch) might be great alternative (it does use pages, but it's much more "lightweight" in terms of UI compared to repeaters).

I'm here. Too much distraction

lol, the title should definitely stay English

Yeah I was speaking about things only visible to devs, but it would feel odd and there's no clear line or hard to see/know, so as said the modules title makes sense to me not to translate. This wouldn't be too bad as everyone would be speaking of "ModulesManager" and not "ErweiterungsVerwalter".

I remember this discussion too. Also Matthias (yellowled) and I talked about how to handle this, but with no final solution. Best would be: one general repo per language (under the roof of official PW?), including "sub-repos" for the basic lang-pack and every translated module. Is such a hierarchy in GitHub possible at all? Also I agree with soma: not absolutely translate the module titles, but the descriptions and the rest of it.

Seriously? If yes, out of the box, no. But with some trickery, you can have MarkupBlog output posts from only a particular author, assuming each author has their own blog. I am just thinking out loud here. If this is a feature request, I'd like to have more details but also hear what others think Glad you like the module.

Around PW 3.0, I'm looking to make PW multi-instance compatible so that you could have multiple ProcessWire instances (each connected to separate databases) running from the same PHP code. This opens a huge amount of flexibility. But it also means that any kind of static references will have to disappear because function calls like Wire::getFuel('var') and wire('var') make the assumption that there is only one instance of ProcessWire running. This is one of the bad things about static calls in general. When that time comes, we will be able to apply contexts to our template files so that calls like wire('var') still work. But the reality is that non-static calls like $this->wire('var'), $this->var, and $var are technically superior when it comes to a multi-instance environment. So my opinion would be that it's not good to introduce new static calling methods when they may soon be obsolete.

I think it would make sense to build the components of a forum in such a way that as many of them as possible could be used in other applications. Designing them in a way that you can use them to build a forum, but also other things. This would mean a broader developer audience and more contributors. I am repeating myself from another thread I have the feeling that actually starting from strong spam prevention (Akismet + SFS etc) might be good, because then you could do public experiments and add more functionality without having to fight spam fires.

I am sure it is achievable, but most people here would argue it's not worth the effort. Most dedicated forum software out there has been developed over several years by teams of people. It is a lot of work to replicate all the functionality. But, if you want something simple in PW, if you haven't seen it, here is a very basic but functional forum module from apeisa: http://modules.processwire.com/modules/discussions/ It might provide a good starting point for you.

AutoLinks has been updated with the following additions: Multi-language support: You can now specify different sets of terms per language. Max linked terms option: You can now specify the maximum terms that will be linked in a block of copy. Markup for links: It will now let you control the markup for auto-generated links and you can specify different markup for internal and external links. Allowed tags whitelist: You can now specify a whitelist of tags where auto-generated links are allowed. For example, if you didn't want it generating links in headlines, you might tell it to only generate links in paragraphs <p> and list items <li>.

Table Use this for tabular data, like rate tables or other things that you might typically represent in a spreadsheet. Use it for situations where you don't need the full-blown flexibility of repeaters, as it's technically more efficient with far less overhead than repeaters. Something like the Events Fieldtype could be very easily re-created via a Table field, but the potential uses are far broader. But for the most part, think tabular data when it comes to the Table field. Multipliers This is good for when you need a range of values (whether text, textarea, numbers, dates, etc.). If you are using repeaters with just one field in them, you might be a lot better off with a Multiplier. Like the Table field, Multipliers are very efficient and low overhead relative to something like Repeaters. Use Multipliers when you need to repeat a single input multiple times, optionally with a min and max number of inputs. Lets say you are building an employee directory, and each employee has between 1 and 3 email addresses. Rather than using 3 separate email fields, you would use 1 multiplier field and specify min=1 and max=3. Repeaters These are infinitely flexible in terms of what they represent, but each row of values is technically a page in the system. As a result, with the flexibility comes significant overhead. This is really only an issue when the quantity of repeater items gets high, or when you have lots (thousands) of pages using repeaters. I recommend repeaters for setting up things like homepage carousels. For example, if you go to the Villas of Distinction homepage, there are 3 separate repeaters in use on that page, each holding a photo, title, description, link. The client can have as many items in each of those sections as they want. Currently it looks like the first repeater as 6 items, the 2nd has 2, and the 3rd has 6. The possibilities of what can be represented with repeaters is endless, but look for potential alternatives when dealing with large quantities (whether large quantities of repeater items, or large quantities of pages using repeaters). PageTable This is one of the ProFields that is available for free (thanks to Avoine sponsorship) on the ProcessWire dev branch. Meaning, it'll be available for everyone to use as part of the core in ProcessWire 2.5. And you can use it now if you don't mind running the dev branch. PageTable has all the flexibility of repeaters, but with lower overhead from the admin/input perspective. Rather than trying to bundle all the inputs on one screen, PageTable shows you a table of items and you click on the item to edit it in a modal window. This enables it to be a lot more efficient from the admin UI perspective. It's also more flexible than repeaters are in terms of where you store your items. PageTable lets you choose where they should live, whether as children of the page being edited, or as children of some other parent page you designate. They might be a little more work to setup than repeaters, but I think that most situations where you need the flexibility of repeaters may be better served by PageTable. PageTable still can't compete with the speed and efficiency of Table or Multiplier, but consider using PageTable anywhere that you might have used Repeaters before. Repeaters and PageTable are fundamentally different from the admin UI/input perspective, so you'd want to compare them yourself to see what suits your individual input needs better. PageTable involves more clicking to create and edit items, making Repeaters potentially faster for entering data rapidly. But PageTable will scale much further in the admin UI than Repeaters will, so I would personally favor PageTable in more situations than Repeaters.

@WillyC you are making great progress with your talking, I remember that back in 2011 it was much worse i donut live with mom.any more she always.fixings thing reword this,clean that.wipe those,flush that written for me.blah blah .enuff i get.my own place fine is my written i coder.not writter

We're proud to release our next and new version of ProcessImageMinimize (1.0) and the minimize.pw service. As mentioned here and on Twitter we've worked hard the last two weeks. The whole service has been rebuilt from the ground to support all the wanted features of the community. It's faster and more reliable, it works out-of-the box and has a new pricing structure. Images are processed async. behind the scenes The service works on a queue now. The service has new compressions scripts with higher quality output, especially for jpg files Build to scale: We can scale the servers in under a minute and handle thousands of images without any problems The module uploads the image and waits until the image is minimized. If activated, the module is now able to replace the original image file instead of creating a .mz variation If activated, the module automatically sends every new image to the service The module also works with apeisa Thumbnails module (CropImage), adding an getMzThumb($name) method While the image is beeing minimized, the module creates a temporary image. You can now set a quality of 100 on your image config without problems Direct link to the new dashboard at the module settings page The module now tells you if you have no volume left. The module also features the "classic" way of using the minimize()/mz() API method on PageImages. A new dashboard for customers features statistics and a quick overview You can see traffic, compression rates, saved bandwidth and more for each website using your license key. You can browse old invoices. New pricing structure The pricing is now based on a volume-based point system. Buy more volume(=images) for your license if you need them. No yearly price, no auto-renewal. And 1000 2000 images for free. A new website with an overhauled design and more feature information A new little minigame to compare minimized JPGs. All the old features like secured https connections, the fail-safe module and our image size reductions. The few existing customers are migrated with some extra volume You can read about the features at our new website. Ready to start? Download the module and read the documentation at Github For the first week, we will give all new users 2000 instead of 1000 images for free. So signup and try the service. This should be enough for alle small- to mid sized projects. If you need more than those two thousand images, you can buy another 5000 for around 19€ or 15000 for 39€. You don't have to update your license key on your module configuration after buying more volume. Paying for the service also removes the three site limit. Attached is a screenshot of our development dashboard and the new homepage. Please note, that we currently don't support a full ProCache installation. At least one PHP call on any site has to be made in order to activate the module. We have a plan to solve this problem but it's not implemented in this release. Also the stats don't display the correct amount of images sent for old customers, because we haven't tracked them before. Thanks for your previous feedback. Thanks to all the developers using our beta. You really helped us. We hope that we can provide a valuable service to the (growing) ProcessWire community. Feel free to ask any questions. Submit your first impressions of the service, the website or any other aspect. As mentioned before, we want to be open and honest.

This thread is used as a place to collect: 1. links to posts in the forum answering (repeating) newbie questions 2. links to posts in the forum and elsewhere on the net giving good insight in processwire 3. links to good articles about processwire 4. links to good tutorials posted in the forum 5. links to movie clips 6. links to posts in the forum talking about modules 7. code snippets or links to code snippets 8. Usefull Helpfiles Many good posts that answers (repeating) newbie questions or give good insight in the how and why of processwire, links to tutorial posts, (also on the net), movie clips, clarifying articles and code snippets are spread over the forum. PM me if you know a link. About this kick start see this post: http://processwire.com/talk/topic/4143-wordpress-dominates-19-of-the-web/page-2#entry40910 This is a work in progress, it takes time to make it grow bigger and better. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = STARTING NEWBIES AND DESIGNERS Link1: Starting and growing with processwire. https://processwire.com/talk/topic/3990-another-simple-photo-gallery-tutorial/page-4#entry61069 Link2: I am basically a designer with some programming skills. My question is this: Can I go ahead to use processwire for this even though i am still learning php. http://processwire.com/talk/topic/3954-starting-out-with-website-intranet-and-internet/ Link3: Feeling overwhelmed http://processwire.com/talk/topic/3215-newbie-overwhelmed/ Link4: Questions concerning PW and it's capabilities http://processwire.com/talk/topic/1557-questions-concerning-pw-and-its-capabilities/ NEWBIES FIRST CODING QUESTIONS link1: Using a default install, I'm stepping through the tutorials, templates, etc and trying to understand the basic concepts behind processwire and at this point in time "head.inc" & "foot.inc". http://processwire.com/talk/topic/3421-footinc/ Link2: I am puzzled why some html tags are starting in head.inc but don't end in head.inc Instead they are ended in foot.inc http://processwire.com/talk/topic/3388-question-about-headinc-and-footerinc/ Link3: Question about not using ?> in processwire http://processwire.com/talk/topic/3370-question-about-missing/ Link4: After you installed processwire, it comes with a default website. What is the best way to fill in your own website ? How do you replace the default processwire website with your own ? http://processwire.com/talk/topic/3379-how-to-fill-in-your-own-website/ Link5:How much extra work/time will I have to put in, as far as understanding and writing php and getting the hang of the PW system, just to be able to create the same responsive designs I would make in HTML/CSS/Javascrip, while also achieving the easiest type of content editing capabilities (in line with what you can get with a CushyCMS type product)? http://processwire.com/talk/topic/3961-new-to-cms/ Link6: I realize what I am confused about was really something quite basic, such as where are the snippets of php code go beside on templates? Can they go on a page as the value of body field for example? http://processwire.com/talk/topic/3383-back-to-basic/ Link7: I'm stuck in something that should be very simple. http://processwire.com/talk/topic/3720-my-first-doubt-using-pw/ Link8: Several questions before I can start. http://processwire.com/talk/topic/3589-several-questions-before-i-can-start/ PROCESSWIRE CMS INSIGHTS Link1: Reading this thread makes you understand processwire real quick. http://processwire.com/talk/topic/5667-help-a-noob-get-started/ Link2: Very good case study from RayDale giving good insight in processwire http://processwire.c...a-a-case-study/ Link3: Symphony or Processwire ? Another good insight. http://getsymphony.com/discuss/thread/79645/ ARTICLES Link1: Why he choses processwire over modx http://www.mademyday.de/why-i-chose-processwire-over-modx.html COMING FROM MODX ? Link1: You've been using MODX but now you've found ProcessWire. It’s totally amazed you and you can’t wait to get started. But…you are wondering where everything is. If this is you, read on… http://processwire.c...ning-from-modx/ Link2: A MODX refugee: questions on features of ProcessWire http://processwire.com/talk/topic/3111-a-modx-refugee-questions-on-features-of-processwire/ Link3: Code comparison between modx and processwire. http://processwire.com/talk/topic/2850-processwire-for-designers/page-2#entry30349 COMING FROM DRUPAL ? Link1: How to move your site from Drupal to ProcessWire. http://processwire.c...ndpost__p__8988 PAGES IN PROCESSWIRE Link1: Understanding pages in processwire http://processwire.com/talk/topic/5667-help-a-noob-get-started/page-2#entry55820 Link2: More about the function of pages in processwire http://processwire.c...fused-by-pages/ Link3: How to hide Pages from the Topnavi via Adminmenu http://processwire.com/talk/topic/2037-how-to-hide-pages-from-the-topnavi-via-adminmenu/ TEMPLATES IN PROCESSWIRE Link1: A good post with code examples to start a template http://processwire.com/talk/topic/43-template-tutorial/ Link2: Template design a better route http://processwire.com/talk/topic/2782-template-design-better-route/ Link3: A different way of using templates http://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/ FRONT-END / BACK-END Link1: ProcessWire Setup and front-end editing made easy http://processwire.com/talk/topic/2382-processwire-setup-and-front-end-editing-made-easy/ Link2: Creating a front-end admin http://processwire.com/talk/topic/2937-creating-a-front-end-admin/ Link3: How would I build functionality and write information from the front-end to the back-end? http://processwire.com/talk/topic/2174-writing-from-front-end-to-back-end/ Link4: Is it possible to create a custom login page like a template ? http://processwire.com/talk/topic/107-custom-login/ Link5: A "members-only" section in the front-end. Integrating a member / visitor login form http://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/ Link6: Trouble deleting pages from the front-end. http://processwire.com/talk/topic/2290-trouble-deleting-pages-from-the-frontend/ MODULE Front-end Edit. It turns the content of $page->body into a clickable area and gives the ability to frontend edit the content via tinyMCE http://processwire.com/talk/topic/3210-module-frontend-edit https://github.com/Luis85/PageInlineEdit/ MODULE Fredi, friendly frontend editing. http://processwire.com/talk/topic/3265-fredi-friendly-frontend-editing/?hl=fredi http://modules.processwire.com/modules/fredi/ MODULE Admin-bar Provides easy front-end admin bar for editing page content in ProcessWire 2.1+. http://processwire.com/talk/topic/44-is-there-way-to-get-information-about-current-user-in-templates/ http://processwire.com/talk/topic/50-adminbar/ http://modules.processwire.com/modules/admin-bar/ MULTI LANGUAGE WEBSITE IN PROCESSWIRE Link1: Multi-language website page names / URLs http://processwire.com/talk/topic/2979-multi-language-page-names-urls/ Link2: API http://processwire.com/api/multi-language-support/multi-language-urls/ Link3: The name of the default language can't be changed in Pw, but the title. http://processwire.com/talk/topic/4145-recoverable-fatal-error/#entry40611 ADD NEW USER TO YOUR WEBSITE AND PASSWORD RESET Link1: Integrating a member / visitor login form http://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?hl=%2Bpassword+%2Breset#entry15894 Module http://processwire.com/talk/topic/2145-module-send-user-credentials/?hl=%2Bpassword+%2Breset BASIC TUTORIALS FOR NEWBIES Link1: Approaches to categorising site content http://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/ CODE SNIPPETS AND FUNCTIONS Link1: Get page id from images object https://processwire.com/talk/topic/6176-get-page-id-from-images-object/ Link2: Function to render Bootstrap 3 carousel markup from ProcessWire images object https://gist.github.com/gebeer/11200288 .HTACCESS EXAMPLES ON YOUR HOSTING SERVER Example1: A working .htaccess file. The issues were that the .htaccess file must exist on the server before installing processwire and that the server did not allow options in the .htaccess file. After fixing that processwire could be installed on the server without any problem. Note that such restrictions might be different on your server that you need to find in the faq of your host. RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?q=$1 [L,QSA,NC] HTML KICKSTARTER Link1: How can i integrate HTML Kickstarter with processwire? http://processwire.com/talk/topic/2731-how-can-i-integrate-html-kickstarter-with-processwire/ MOVIE CLIPS Field dependencies are coming in ProcessWire 2.4. Field dependencies are basically just a way of saying that one field depends on another. It dictates which fields should be shown in a given context. https://www.youtube.com/watch?feature=player_embedded&v=hqLs9YNYKMM HELP FILES Cheatsheet Link1 Cheatsheet 1.1 as pdf file Download: http://processwire.com/talk/index.php?app=core&module=attach&section=attach&attach_id=1299 Link2 Cheatsheet is now a processwire site (great work by Soma) http://cheatsheet.processwire.com/pages/built-in-methods-reference/pages-find-selector/ INTERVIEWS Link1: About the history and coming to be of processwire http://processwire.com/talk/topic/4084-about-ryan-and-processwire-an-interview-with-ryan-cramer/

You can use the InputfieldMarkup to add custom markup. $field = $modules->get("InputfieldMarkup"); $field->markupText = "<p>your html string here</p>";

Just hitting my head to a wall with this: I have defined a field like this: $field = $modules->get("InputfieldRadios"); $field->label = "Gender"; $field->addOption('girl', 'Girl'); $field->addOption('boy', 'Boy'); $field->attr("name+id",'gender'); $form->append($field); and try to save the field after submit with this: $form->processInput($input->post); $uploadpage = new Page(); $uploadpage->gender = $form->gender->value; //OR $uploadpage->set($form->gender->name, $form->gender->value); But it doesn't save the field value. With Ryans FormTemplateProcessor module this template works, but trying to do the "dirty work" manually, I just can't get radiobuttons or checkboxes to save. What is it that I don't understand here? EDIT: OK, Soma helped me on IRC: Change $field->addOption('girl','Girl'); to this: $gender = $pages->get("/options/gender/")->children(); foreach ($gender as $p) { $field->addOption($p->id,$p->title); } This is because I am using pages as options. Then save the field like this: $uploadpage->set($form->gender->name, $form->gender->value); Thanks to Soma!