adrian

I can't seem to get it to work, but in a rush and maybe missing something obvious, but soma has this module: https://github.com/somatonic/FieldtypeImagesSelect I think that might do what you guys are looking for.

Or use: http://modules.processwire.com/modules/protected-mode/ If you are giving them a user account for the admin anyway, you may as well make use of it for accessing the front-end during development also. Much cleaner for them rather than having to login via the htpasswd entry, and then again for the PW admin panel. If you don't want them to have admin access you can still use this module and give them a guest role only!

Unfortunately this latest version results in nothing being saved for the field value, no matter whether I use single, multiple, or ASM Some more new thoughts: I think you need that note back that mentions that you need to save the page to populate the options dropdowns. I'd love to see checkboxes and radio buttons added as Inputfieldtype options. Thanks again for working on this!

It's a PW variable and yes you can use it in your templates/modules if you need to do a direct SQL query. There's not that much on it, but a few posts that might give you some background/info: https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=36787 https://processwire.com/talk/topic/1918-mix-api-with-standard-query/ https://processwire.com/about/news/introducing-processwire-2.4/

That error does seem to be related to eAccelerator. Looks like it doesn't support anonymous php functions (http://snippets.webaware.com.au/howto/eaccelerator-and-php-closures-dont-mix/) - there is one on that line in the SessionLoginThrottle module. I think you might have to disable eAccelerator. Maybe go with APC or Zend?

Good to hear - it would still be great though to know what version of PW you are running, just in case the issue hasn't actually been fixed.

What version are you running? It looks like one of the dev versions given that in master there is no attr call on line 1014. The error relates to the newish InputfieldIcon so I think maybe you have a version that had a bug where this wasn't installed when called. Running Modules > Refresh should sort it out. For reference, here are two Github issues about it: https://github.com/ryancramerdesign/ProcessWire/issues/891 https://github.com/ryancramerdesign/ProcessWire/issues/873 If you are running a dev version after this was meant to be fixed (which I suspect you might be based on the line number), can you please make a note on that Issue?

Just to add to kongondo's info, there is a little helper variable ($database) for PDO database work: $sql = "Your table and field creation statement"; $query = $database->prepare($sql); $query->execute();

Good to know! I think it might be worth you creating a converter that can be run via a cron job. Sorry I don't have time for a detailed example, so this might not be much use, but you can use one of the PHP xml to array (or maybe json) functions and then use the PW API to convert that into pages. It won't be terribly difficult, but not exactly trivial. There are several bits of code that might help you if you decide to tackle this - some from the Wordpress Migrator (xml to json) and Migrator (json to PW pages). If you're willing to have a go, I am sure we can help you get through any roadblocks that come up.

Not sure about elastic search, but this module (http://modules.processwire.com/modules/indexer/) allows you to index content inside doc and pdf files. Does that help at all?

Hi @aaronjpitts and welcome! A few tools that might help you: CSV importer: http://modules.processwire.com/modules/import-pages-csv/ Table CSV Import/Export http://modules.processwire.com/modules/table-csv-import-export/ Wordpress Migrator https://github.com/NicoKnoll/MigratorWordpress Migrator (json export and import) https://github.com/adrianbj/ProcessMigrator Please let us know if you have any specific questions about any of these.

That's very defeatist It's not "currently" possible, but I am sure there is something that can be put together - Marty, I have your thoughts from our conversation filed away for a rainy day, or if someone gets to it before me that would be nice too

I am not sure I understand why they can't be referenced to your site root - is it just a matter of keeping things all together? <link rel="import" href="/bower_components/paper-input/paper-input.html" /> Actually looking into this more, I see that import is not supported in Firefox and apparently there are no plans to support it: http://caniuse.com/#feat=imports I guess the platform.js polyfill is making it functional across all browsers - is that what you guys are using?

Wouldn't it need to be pasted into HTML mode? Did CkEditor use to support pasting html into the main view? I think I am missing something I always knew Hanna took a little while to download - I never realized just how big the bundles ACE is. I don't really understand when owzim's new ACE module is only 1.6MB. Perhaps Ryan needs to trim that down - looks like it includes source code, demos etc. But, that said, why does it matter to install it - it's not like those source code files are doing anything. Hope the plugin that Macrura pointed out helps!

This is getting cooler and cooler A few more comments / suggestions. In ASM Select mode, everything seems to be working fine, but I am getting this notice: Warning: Invalid argument supplied for foreach() in //site/modules/FieldtypeSelectExtOption/FieldtypeSelectExtOption.module on line 312 You should probable change your DB queries to use PDO and prepared statements. Here is a note from Ryan (https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=36787) - at some point procedural mysqli functions will no longer be supported - I am not sure when, but better to be ahead of things (I know there lots of modules out there that need updating). The $page->myfield->row['land'] approach seems to work just fine. It's a shame it won't work as $page->myfield->land, but I as you mentioned, I guess the issue is $page->myfield->data, which would be a common requirement. I haven't time to investigate right now to see if I can find a workaround, but I don't think it really matters - what you have is easy to use and an awesome way to access data from all sorts of DB tables - brilliant!

Are they pasting into Source code mode? Regardless, you want to add the script tag to your template file. Would Hanna be an easier solution?

# Block access to any PHP or markup files in /site/templates/ RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ [OR] You can't link directly to php, html, tpl, or inc files in the templates directory, or its subfolders. You'll need to place them somewhere else!

Well the SQL command for basic replaces of the "body" field would go something like this: UPDATE field_body SET data = REPLACE( data, 'search_word','replacement_word' ) The key thing for me when using the PW API is to limit it to just the fields and pages with matching results, rather than iterating and saving every field on every page on the site.

You can delete any module manually - just use something like PHPMyAdmin and browse/search the "modules" database table and remove the row for the module. Then remove the module folder from the server and you should be good. In the case of this module, there are also some additional db tables to remove, prefixed with "version_control", but be careful to remove the ones for the version of version control that you want to remove. Also, note that Version Control supersedes Version Control for Textfields. The latter is only still around for older versions of PW.

Absolutely and I have done that several times in the past, but I want to create a tool that can be used by your clients for site maintenance.

Hey Pete - nice one! I know your code is meant as a quick snippet to get the job done, so no offense intended, but the concerns I have with this is: On a site with a LOT of pages, that could be very slow. I don't like the fact that it re-saves every page, regardless of whether there is a change or not, which will affect the modified date and modified user. I have actually already made a start on a feature rich search and replace module which I will get around to finishing up sometime soon. It provides the ability for searching and then showing the search term in context for each match. You can then choose which matches get replaced, or replace all. Stay tuned!

Not sure why this hasn't been mentioned, so I am wondering if I am missing something relevant, but why not use the $template->noSettings option? Do you need to hide on a page basis, rather than per template? Anyway, if it suits your needs, turn on advanced mode in your config.php file and then you will have a Disable Settings Tab? option on the Template's System Tab. Hope that might help.

@sgt.blikey - I am glad you like it. I have put together a fix for supporting repeaters - please let me know if it works for you as expected. If anyone sees any issues with normal Table fields (not in repeaters), with this new version, please let me know! Even though I just added support for repeaters, I want to make sure you have you read this thread: https://processwire.com/talk/topic/8832-error-in-complex-form/ - it is in the Profields support board, but I am assuming you have access. In particular read the post by Ryan where he says that Tables in Repeaters are not officially supported, although he does say that if they were working and now aren't, he'd consider investigating. Mostly just wanted to warn you that maybe you will run into other issues with this approach. Have you considered switching to PageTables or even simple child pages and putting your Table field in those?

What apeisa said, but that error makes me think you've got something incorrect in your Details > Select Options textarea because $value is not being set. The only way I can make that happen is to have more than one ":=" on a row. Of course the module should have a better check on this, but I still think you might have something incorrectly configured. EDIT - I see you found your error

I think I am maybe confused, but shouldn't it behave like other PW muilti fieldtypes. That is, you should be able to do: foreach ($page->selectextoption as $selectedoption) { echo $selectedoption->id //returns 1 echo $selectedoption->name // returns title } //OR $page->selectedoption->first()->id I don't really understand why you need to look up $data['29']. I am assuming 29 is the integer that has been stored and is what $page->selectextoption would currently return if using a single select field. In the case of a single one you would just return the corresponding db fields as properties of the field, like my example a couple of posts above. If it's a multi-select field, then it should return an array of results that you can foreach through or grab a specific index (first, eq, last). Am I missing something?