Leaderboard

I'm at gym reading tweets between sets so will read/reply better later. But have you looked at the LanguageSupport module that installs/uninstalls its own related modules?

I sometimes use CSV import module to create lots of pages from one list or names or titles. It's very handy and even can import images or files from an old website.

This module enables you to limit edit access (by role) to any field in the page editor. This essentially provides field level access control on top of the existing access control system. It removes access to fields within a template, which is something that the built-in access control does not currently do in ProcessWire. This gives you a nice and simple granular control of fields. For instance, you might have two users (with different roles) that have access to edit a page, but only one of them could edit a particular field you had limited access to. Another example might be if you (the superuser) wanted to keep a notes field that only you would see in the page editor. But those are just simple examples, and the possibilities are quite broad. I've been wanting to find a way to provide field-level access for awhile, so this module has been on my mind for a bit. But what motivated me to finish it was a need that came up earlier today by Raymond Geerts in this thread where he needed the ability to limit access to fields on the page's settings tab... this module would do that quite nicely. http://modules.processwire.com/modules/page-edit-field-permission/ https://github.com/ryancramerdesign/PageEditFieldPermission How it works This module hooks in to modify the behavior of Page::editable, which is used throughout ProcessWire, but most notably by Page Edit. This module looks for permissions in the system that follow the name format of page-edit-[field] where [field] is the name of an existing field in the system. When it finds such a permission during a Page::editable call, it checks to see if the roles from the current user have this permission assigned. If they do not, then permission to the relevant field is refused, thereby preventing edit access to the field. This module also hooks into the Page Edit process and simply removes fields that the user doesn't have access to edit, before the form is rendered or processed. How to use it Once the module is installed, you get a set of checkboxes on the module configuration screen. Check the boxes next to each field that you would like it to create permissions for. (Alternatively, you can create the permissions yourself, so this is just a shortcut). You should only create permissions for fields that you intend to limit access to. Once your new page-edit-[field] permissions are created, any non-superuser roles that previously had access to edit those fields will no longer have access to edit them. To give them access, you must edit a role and check the box for the relevant permission.

The main reason why name isn't on the content tab by default is because you could be breaking links (internal or external) every time you change it. It's one of those things that ideally should never change after its been created. But if you do expect changes, I suggest installing the Page Path History module, which will keep track of those changes and setup 301 redirects.

Already solved. This helped: http://processwire.com/talk/topic/225-how-to-work-with-ajax-driven-content-in-processwire/

This is not specific to PW projects, I would use the same approach or techniques for plain HTML sites or projects with a blog system. This is because I always start with an HTML prototype which later is converted into a PW template. I actually have … well, I wouldn't call it a framework, but a “starting point”, a boilerplate. This is derived from the HTML5 Boilerplate and combined with some basic CSS and JS stuff. Just some reliable CSS (see later) snippets and jQuery plugins I use often or all the time. Having (and knowing) that helps a lot, but beware - it can result in repeating yourself in your designs. I also have a (small, but growing) collection of PW snippets, most of them stripped from the default page profile or used in projects. (Also saves me having to look it up in the forum again.) Two other things which have really helped me to save time … well, it's not so much about actually saving time, but more about saving nerves by not having to manually do things … anyway, it's using a CSS preprocessor (I prefer Sass/Compass, but I honestly think it doesn't make a big difference if you prefer LESS or Stylus) and a build process to automate things (I have recently switched to a Grunt-based build system, but other build scripts should work just as good) like combine/minify CSS/JS, optimize images etc.

I'm using a nice variation of the infinite scroll http://www.fieg.nl/i...a-jquery-plugin This plugin it's really easy to use, it doesn't requires any particular modification in the code because it uses the pagination links to generate the infinite scroll, in this way also google is happy because I generate my content with pagination as usual and the users have the enhanced version.

Soma has a lot of great modules! Check his teflon admin theme to!

Just installed it trough Module Manager too, works great as far i can see. Straight forward logic. Going to do some more testing comming monday when im at the office. Thanks for this. @Soma also thanks for the Module Manager that works realy nice and easy

Just found this thread and it set me off exploring to see what debugging features were possible in Vim. I've not used a proper debug environment/IDE with PHP though I used to with assembly/C/C++. I found an excellent plugin (joonty/vdebug) that, coupled with XDebug, works amazingly well and allows you to single-step, watch variables (global and local scopes), set breakpoints on lines/conditions and do evaluations - in short, all the usual suspects. I've been using it to single step through PW as it builds pages - neat!

Thanks both of you, I've got it working as expected. I've also got my extended user system working quite nicely with adding/editing students/users front-end if anyone else gets stuck and needs a pointer.

Just tested and downloaded and installed via Modules Manager. Works great so far! Thanks for this module Ryan

There's also a textformatter for the Textile lightweight markup system if you'd prefer

Step 1. create a PW template like this: <?php if($input->get->offset){ $results = $pages->find('template=articles,start='.$offset.',limit=20'); } foreach($results as $item){?> <li><?=$item->body?></li> .... your html here .... <?php }?> Step 2. In the page that you want infinite scroll, do something like this in JS .... when the user scrolls to the bottom... $('body').append('<div id="section"></div>'); $('#section').load('/path-to-my-page-with-template/?offset=40'); ... Figure out how many items you want to load, calculate your offset ... None of this is production code. Just trying to show the concept.

Do you get paid for the sites that you would with PW? When you come to the forums to get help, do you limit your questions purely to development work that you are doing for free? I originally developed PW to help us all create better sites in less time, and with more fun. I'm hoping that PW is helping others to be more competitive in all ways, including financially. But recognize that PW did not come into existence on its own. Years worth of time and money has gone into making ProcessWire happen. If you are using ProcessWire to develop sites you get paid for, then you are profiting from ProcessWire. And that's fine with me, no ROI is expected or wanted--I've never asked anyone for anything. But it is disheartening to hear a user make a statement with the implications yours makes. Form Builder is not about making a profit. I don't expect that I will ever make enough on it to offset the actual time investment on it. My hope is that eventually it will be something where the community and myself have split the cost to create. If I wanted a profit, I would go make a Form Builder for WordPress or Drupal where the user base is large enough for that potential to exist. Form Builder is a tool that wouldn't exist if I had to fully self fund it. It's also an experiment to determine if I can reduce my client workload and substitute some of it with ProcessWire-related development that benefits all of us. But I can't substitute something that supports my family with something that doesn't. Form Builder is here to benefit you, not me. If you build sites for a living (or even a hobby) it's going to pay for itself the first time you use it. If you previously spent half a day building a form, now you can spend minutes and get a better, more secure and capable result that can do all sorts of things with the results it collects. Also want to note that Form Builder is something completely different from the original subject of this thread and I don't view them as similar products at all. Likewise, Form Builder is completely different from something like Zend Form or others like it. One does not preclude the use of the other and we should all keep more than one tool in our forms toolbox. I fully support Clinton's project and any others that benefit forms in ProcessWire. Forms are one of the most diverse and important aspects of web development. I feel very confident about the value of Form Builder in your toolbox, so have made it 100% refundable if you find it isn't for you (this type of return policy is pretty rare with digital products).

You can also just call it /site/ if you prefer. We only use /site-default/ initially so that people can continue to keep it cloned easily via Github without worry of it overwriting anything in their /site/ dir. As a result, there is no /site/ dir on the GitHub source (instead it's /site-default/ solely for GitHub). This is correct. Also note that the installer moves /site/install/files/ to /site/assets/files/. So if you were creating a new profile, you would copy your /site/assets/files/ to /site/install/files/ before zipping up your /site/ dir into a new profile. Also correct. This is so that you can create a site, and then easily export it as a profile just by exporting the database. The installer requires a fairly simple SQL file since ProcessWire uses PHP's MySQL commands to create the DB and insert rows. so things like extended inserts and such probably won't work. So here is the command I use to create a dump for a new profile: mysqldump --complete-insert=TRUE --add-locks=FALSE --disable-keys=FALSE --extended-insert=FALSE --default-character-set=utf8 -u[user] -p[password] [db_name] > install.sql After that, I edit the dump file with a good utf8 compliant editor (I use BBEdit/Textwrangler), and remove any extra junk that MySQLdump adds at the top and bottom of the file. This means remove anything that is not a "CREATE TABLE" or "INSERT" statement, unless you specifically want it there. Then I find the part where the insert statements are for table "users" and I remove all users except guest (ID 1). Likewise, remove all the insert statements for table "users_roles" except for the first one, which assigns role "guest" to user "guest" (1,1,0). Then your install.sql is ready. You are correct on all of this. You basically just create the site you want the profile to be. However, you shouldn't need to manually delete any images from assets, as deleting them on the page (or deleting the pages you don't want) will handle deletion of them automatically. This is right, but you can exclude everything from assets other than the dir itself. Your /site/assets/files/ should be copied or moved to /site/install/files/ (as mentioned above) before creating your profile. Why do we do this? Well if you deliver the profile with /assets/files/ already in place, and the file permissions weren't retained for one reason or another (like when they FTPd them or something), then you'd have to tell the user how to make all of the files in /assets/files/ writable. If they don't have shell access, this could be a time consuming process... a lot harder then just making /site/assets/ writable. By making ProcessWire move them from /site/install/files/ to /site/assets/files/, it ensures that there can be no issue with messed up file permissions, since ProcessWire will have created the files. If for some reason, ProcessWire can't move them from /site/install/files/ (like if permissions were lost when the user uploaded the files), then ProcessWire will copy them instead. Either way, it'll be able to complete the install with minimum hassle to the user. For the time being, the install profile will include the entire database. But not having made a lot of different install profiles yet, I've not given a lot of thought to doing it differently. It is possible that the core tables will be created/installed separately in the future. If you want to make something future proof, perhaps I should go ahead and make that change now... moving the core table creation outside of the site profile. This won't be too difficult from this end, and I imagine I could have that chance in place within a week. If it helps, here is my profile creation shell script. It creates a profile from a site that is running, so it goes and moves things around temporarily, creates the zipped profile, then moves them back. You'll see several things that get renamed to a ".old" version. My zip command (and .gitignore file) excludes files ending with ".old", so they are basically removed from the picture temporarily. I run this script after I've already exported the database, and placed it in /site/install/install.sql, using the method mentioned above. #!/bin/bash cd /Users/ryan/htdocs/sky/ <-- sky is the root dir of my PW installation chmod -R og+rw ./site/assets/* rmdir ./site/assets/files/* <-- this removes blank directories mv ./site/assets/files/ ./site/install/files/ mv ./site/config.php ./site/config.php.old <-- take the live config.php file out of the picture temporarily mv ./site/config-original.php ./site/config.php <-- and use a config.php without DB settings in it mv ./site/assets/cache/ ./site/assets/cache.old/ mv ./site/assets/logs/ ./site/assets/logs.old/ mv ./site/assets/sessions/ ./site/assets/sessions.old/ mv ./site/assets/installed.php ./site/assets/installed.php.old zip -r -v ./site.zip ./site/* -x@zip_exclude.lst <-- create the zip file, excluding stuff mentioned in zip_exclude.lst mv ./site/install/files/ ./site/assets/files/ <-- now move everything back so our site will still work... mv ./site/config.php ./site/config-original.php mv ./site/config.php.old ./site/config.php mv ./site/assets/cache.old/ ./site/assets/cache/ mv ./site/assets/logs.old/ ./site/assets/logs/ mv ./site/assets/sessions.old/ ./site/assets/sessions/ mv ./site/assets/installed.php.old ./site/assets/installed.php And here is my zip_exclude.lst file, referenced in the "zip" command above. You may not need anything other than the "*.old" and *.old/*" in yours. But I'm running on a Mac and use VIM, so most of these clear up potential files related to those. .DS_Store *.DS_Store *.old *.old/* sess_* *.cache *.swp *.sh Thanks for using it! Ryan