Lance O.

There is a Update image alt attributes checkbox in the Markup/HTML (Content Type) section of the Details tab for the ckeditor field. But checking this option doesn't seem to do anything when embedding new images with descriptions.

I have a template that includes an image field that supports multiple images. The images uploaded to this field include a description field.

If one of these images is embedded into a textarea field (i.e. Body), should the image description will be inserted into the image's alt attribute when embedding the image?

I always assumed that it would, but there is a separate option to add an alt attribute when inserting the image.

Is the purpose of the description field purely for use with the API and unnecessary for images that are intended to be embedded within a textarea field?

I guess I need clarification as to how this works. Either something changed, or I never understood the differences between the image description and the alt attribute as it is used in ProcessWire.

I'm currently using ProcessWire 3.0.15.

Deleted and works as expected. Thank you!

Hmmm, I see that the ImageExtra 0.0.2 module is uploaded to the server, but it isn't installed. I don't remember installing it and using it, but then again, I've been working on this site since last July (!) and I may just be forgetting.

Is it okay to delete "caption" from the database?

The field type is definitely set to "Image." There is no caption option. :-(

Here is the field export, if that helps:

{
    "portrait": {
        "id": 144,
        "type": "FieldtypeImage",
        "flags": 0,
        "name": "portrait",
        "label": "Portrait",
        "extensions": "gif jpg jpeg png",
        "maxFiles": 1,
        "outputFormat": 2,
        "defaultValuePage": 0,
        "inputfieldClass": "InputfieldImage",
        "collapsed": 2,
        "descriptionRows": 1,
        "adminThumbs": 1,
        "defaultGrid": 0,
        "maxReject": "",
        "fileSchema": 2,
        "icon": "image",
        "overwrite": null,
        "outputString": "",
        "textformatters": "",
        "entityEncode": "",
        "useTags": "",
        "showIf": "",
        "columnWidth": 100,
        "required": "",
        "requiredIf": "",
        "unzip": "",
        "maxWidth": "",
        "maxHeight": "",
        "minWidth": "",
        "minHeight": ""
    }
}

Does anyone have any ideas on what is happening here? I have a lot of images I need to upload to my client's site and I can't because of this error message.

I upgraded to ProcessWire 3.0.15 and it looks like the changes in that version have fixed the problem. 

Thank you, BitPoet and horst.

It looks like some things have changed in ProcessWire 3.x. See "Improvements to the ~= operator in page finding operations" in the following post:

https://processwire.com/blog/posts/merry-christmas-heres-processwire-3.0.3-and-2.7.3-and-some-more/

I'm going to upgrade the site and see if this helps with the results. If not, I'll try splitting each search term as mentioned above.

I've set up search on a client site and discovered that the search results are a bit finicky.

Searching for meter returns a faculty page with the title of "Timothy L Van Meter". But searching for van meter returns no results.

My selector looks like this:

$pages->find(template=campus-view|campus-view-archive|campus-view-article|component-event|component-feature|component-post|component-showcase|component-video|faculty|faculty-directory|home|news-archive|news-publications|page|post|section|seminary-hill-farm|slide|staff|staff-directory|videos,title|headline|heading|subhead|lead|body|profile|summary|meta_keywords~=van Meter,limit=12);

Changing the selector operator to %= produces results, but the client doesn't want visitors to the site to have to enter an exact word or phrase.

Can someone explain why the more specific "van meter" does not display in results, but that "meter" does?

I'm receiving the following error when uploading to an image field named "portrait":

SQLSTATE[HY000]: General error: 1364 Field 'caption' doesn't have a default value

Settings on this field:

Valid file extensions = gif jpg jpeg png

Maximum files allowed = 1

Formatted value = Single item (null if empty)

Text formatters (for file descriptions) = no selection

Overwrite existing files = checked

Number of rows for description field = 0

The site is hosted on ServInt and I'm using ProcessWire 2.7.3 dev.

Is this error that can be corrected by changing the SQL mode, or is this a ProcessWire error? Any insight is appreciated.

Great, thank you!

I'm using 2.7.2, although I upgraded from a previous version (can't remember which one). 

When exporting a field to be used on another site installation, is there any harm in removing send_templates from the export code?

{
    "vcard_tel": {
        "id": 134,
        "type": "FieldtypeText",
        "flags": 0,
        "name": "vcard_tel",
        "label": "Phone",
        "textformatters": [
            "TextformatterEntities"
        ],
        "maxlength": 2048,
        "tags": "vcard",
        "collapsed": 2,
        "size": 0,
        "send_templates": [
            54,
            53
        ],
        "showIf": "",
        "columnWidth": 100,
        "required": "",
        "requiredIf": "",
        "stripTags": "",
        "placeholder": "",
        "pattern": ""
    }
}

I've always used a PHP file that resides outside of PW and included an include to the index.php page, but if you are working within PW, you probably don't need to include this at the top of your template:

include("/home/path/to/public_html/index.php");

Image bottleneck or not, if the PW admin is loading slowly, there must be another issue. This site didn't load this slowly in the past. Images are uploaded via the studio that designed the site, so I don't have complete control over what gets added.

The site was originally using 5.3.29 FastCGI, but was changed to 5.5.21 CGI (latest).

I just added that bit of wizardy to the .htaccess file as DaveP suggested. Seemed to make a little bit of a difference, but the backend still loads slow.

Yes, shared hosting. Not my choice, since I always recommend ServInt VPS for hosting. I'll contact the client and let him know that his hosting plan needs upgrading.

Thanks for the compliments on the site!

The following site developed in PW loads very slowly. I updated PW to 2.7.1, but I don't know if that is the culprit, since the client told me that the site was loading slowly for a couple of days before the upgrade.

The site is hosted on Media Temple Grid and is using PHP 5.5.21. Both the public site and the PW admin load slowly. Media Temple has suggested adding a MySQL GridContainer.

Any ideas? This is the first time I've encountered this problem, and I honestly don't think PW is to blame. Currently, I don't have caching enabled, but even if I did, that wouldn't help the PW admin. Anyone else hosting on Media Temple?

http://richrosendale.com/

It looks like setting up the Source URL with the additional code works. (It doesn't look like we need to add the additional code to the page url.)

Thank you for your quick response! Client is happy and has restored faith in PW and Jumplinks.

I am using Jumplinks for one of my clients. We have set up a number of redirects to monitor several campaigns we have in place. For instance, we have links like this:

http://website.com/bioh

that redirect to actual pages in the site:

http://website.com/biohealth/

The original link is being used in Google AdWords. AdWords is adding a Google Click Identifier (gclid) to the url, so when a user clicks on the link, it actually appears like this when they visit the site:

http://website.com/bioh?gclid=CPaHlL3_jckCFdc9gQod4xEB4g

The problem is that the link with the gclid parameter is returning a 404 error. Jumplinks doesn't appear to recognize when a parameter is appended to the url.

Is there a way to prevent this, or perhaps I didn't set something up correctly? Any advice is appreciated. I'm using Jumplinks 1.3.1 with ProcessWire 2.6.1.

Thanks, all. I'll check out the modules mentioned above.

No offense to the developer of FrontendUser, but I'm cautious about using modules that provide functionality that are core to a project's success. I came from the WordPress world and was burned more than once on plugins that were no longer supported by the developer. I'm at the point where I would rather spend $100 on a module and be confident that it is going to be supported rather than using a free module that may later be abandoned.

Yes, basics like registration, login, change password, email address, name, and upload image would need to be supported, allowing users to edit their profile using a custom front end template without having access to PW's back end admin.

I'd love to see the next Pro module provide an easy way for front end visitors to register an account and edit their profile.

My preferred approach is to create a high level "Slideshows" page. Then I will create a parent "Slideshow" page and add individual slides as child pages. On the page where a slideshow needs to be assigned, I create a Page field that allows for a single slideshow selection.

Using repeater fields is a bit limited in that you have to completely delete the slide from the slideshow if you no longer want to use it. Some of my clients want to unpublish a slide and then use it again in the future. Using pages as individual slides provides them more flexibility, and using pages as slideshows allows them to create a variety of slideshows that can be swapped out. For example, a client may want to change Home page slideshows on a seasonal basis.

Processwire is chosen, wordpress is followed.

I like ProcessWire, and I've used it on almost every project in the past three years. But to state this in the way that you have is borderline trolling. You are of course entitled to your opinion, but in my world, things aren't as easily defined in black and white. And they aren't for my clients, either.