adrian

Absolutely - you will need to forward this onto your hosting provider so that they can remove this restriction.

Hi @ali.donde - welcome to the forums. Sorry, I am in a rush right now, but to help more we will need to know the ajax error. If you click on the Network tab of you dev console and then the Response - have this open before you upload the image and tell us what you get. I expect it's a php Warning, hence the "W"

But at least Tracy would give you a chance to debug and test your code changes on-the-fly and maybe save yourself from becoming a dead bugger! PS - I am not sure how well "bugger" translates to those here from non English colonies For those looking for this, this is the definition you want: http://www.urbandictionary.com/define.php?term=bugger&defid=1454790 and definitely not this one: http://www.urbandictionary.com/define.php?term=bugger&defid=734856

Do you have debug mode turned on in site/config.php ? That .htaccess error in your log looks suspicious.

I wonder if it has anything to do with using a string for the version number? I am switching my modules over to string version numbers as well, so would be good to know if that is the problem?

Hi @theo - this looks related to (https://github.com/adrianbj/ProcessMigrator/issues/4). What commit are you using? Please try this one (two back from current) - https://github.com/adrianbj/ProcessMigrator/tree/3e2121b8fdb68e9d9dc0c6aca8aae75e923a2669 I will likely recreate this module in the future after Ryan fully implements the new core methods for exporting/importing pages http://processwire.com/blog/posts/roadmap-2017/ I just don't have the time to put more effort into the current iteration of this, especially given that future versions should make use of the new core features.

Any chance you are running an old version of the module. That method is no longer used: https://github.com/horst-n/CroppableImage3/blob/e87b602cffbbdd648a48aa7a4975f927ff58f4d7/FieldtypeCroppableImage3/FieldtypeCroppableImage3.module#L80-L81

Sounds like a namespace issue because bootstrapped files don't get run through the file compiler you will either need to add namespace ProcessWire; to the top of the file, or do: $page = new \ProcessWire\Page(); to reference the ProcessWire namespace

Any chance you are running InnoDB on a version of MySQL that doesn't support fulltext indexes. I think it was introduced for InnoDB in 5.6.4

Thanks for the feedback @Macrura - I have often wondered how much use the template path (and template editor) panels were getting. Glad to hear that it helped you out

The custom PHP option in @Robin S' module (http://modules.processwire.com/modules/custom-inputfield-dependencies/) should make this possible.

Another minor (but hopefully useful addition) - you can now use keyboard shortcuts to move between items in the console panel history stack. Back: CTRL+CMD+↑ Forward: CTRL+CMD+↓ The up and down arrows are to mimic unix based terminal history shortcuts. Unfortunately I had to add the CTRL+CMD in there as well because it's hard to find a combination that isn't already used for something else, either by the browser or ACE editor. Anyway, hope you will find it useful for speedy switching back and forward between snippets of code you have recently run.

A few updates to the server type indicator ribbon: It's now possible to display it on the frontend as well. It might seem weird, but on occasion I have been looking at the frontend in the wrong tab (live vs dev) and wondering why my changes aren't doing anything You can now hide the indicator along with the Tracy debug bar when you use the hide icon. Here is the css to use if you'd prefer to have the indicator along the bottom: body::before { content: "[type]"; background: [color]; position: fixed; left: 0; bottom: 0; color: #ffffff; width: 100%; padding: 0; text-align: left; text-indent: 5px; font-weight: 600; text-transform: uppercase; z-index: 29999; font-size: 15px; height: 22px; line-height: 22px; pointer-events: none; } which looks like this rather than the default sidebar. It is of course also fixed so it always visible when you scroll.

Any chance there is a page that is assigned to a template_id that doesn't exist?

Did you check the template id of the repeater template against the template_id specified in the data column in the "fields" table for the repeater field? And of course remember that repeater templates are named: repeater_repeaterfieldname

Here's one example: https://github.com/processwire/processwire/blob/50f2834a0ae2a9f9f2ac53439184ebdc04db2f54/wire/modules/PagePaths.module#L216-L222

Ah yes, the next step in the puzzle. This is where you'll need to match the id of each row in the templates table to the appropriate "templates_id" field in the Pages table. No magic here, just careful manual matching. I wouldn't touch the Pages table at all though - be sure to change the id in the templates table.

Yes - that's right in both cases! Let us know how you it goes.

I can help out if you want, but I would have a go at it yourself first. The part that I could do really shouldn't take that long via PHPMyAdmin or some other MySQL GUI. The time consuming bit will be the template access/family settings which I wouldn't know how you would want configured anyway.

Not planning on it - just trying determine whether the post actually belongs in the PW forums or not

Do you still have the fieldgroups table? So long as you don't have any unusual settings where a template is using an alternate fieldgroup, you can probably build this back up again with relative ease. I would start with a templates table from another install and delete all the templates which aren't relevant to the problem site. Then use the fieldgroups table to get the names of the templates and the fieldgroups_id value for that column in the templates table. Once you have rebuilt all the rows in the templates table, I would manually add back the template access / family settings etc. Hope that makes sense and helps. Good luck!

@Kelc12 - are you specifically wanting to use ProcessWire for the backend to this app?

It's not a bug - when saving, output formatting has to be off. PS - you should get familiar with Tracy: bd($page->of()) is a lot easier than messing around with ob_start and var_dump

Well, that's weird - here it returns true or false. Anyway, we are getting off track. Either turn on output formatting before $event->message, or simply add first() before url and you should be fine. Does that work or not?

Do a little experiment and dump or bd($page->of()); before your $event->message and see what you get.