nwjames

@valicesupport,

As Ben Balter indicated, V5.1.0 has introduced a different method of loading the document (wp.media instead of async-upload and managing the document attachment_id within the post_content field entirely on the server. This means the binding process between the upload and plugin processing on the client side is essentially eliminated. It was this that was causing the problems you were seeing.

It would be useful to know if this is now resolved for you.

@ennisprinting,

I believe that Ben was asking whether you were using the experimental document admin screen using Gutenberg (which uses wp.media) or the Classic screen (with async-upload) for document admin. With V5.1, as indicated both now use wp.media.

Again it would be useful to know your experience with V5.1.0

Regards,

Neil James

@valicesupport ,

This fix is included in V5.1.0.

Regards,

Neil James

@mannilito,

Thank you for raising this issue. Version 3.8.1 includes PHPStan as part of its process to improve its quality. The function add_revision_num_to_title is indeed defined as a filter to the_title since its job is to modify the displayed title. Since the definition of the_title parameter is to be an integer, the code says that we will ensure that it is an integer or null when it is called.

You suggest that “Add type and value checks in add_revision_num_to_title() to ensure $post_id is an integer before processing”. This is, of course, exactly what is happening. It is being done by PHP itself and before our processing starts. Some earlier process is calling the_title incorrectly.

We can, and will, look to change our plugin to be more tolerant of other plugins passing incorrectly-typed and/or inappropriate parameters.

We do not determine where the_title is used within WordPress. I can understand that it could be a menu with a pointer to a page, for example. However, it would always be in the context of a post – and for this it uses an integer post_id. Passing a random string makes no sense.

Since it is not the first parameter (which can change value as the various filter functions are called in turn), you could try looking further in the trace stack to find what code is calling the_title with an erroneous value and raise an issue with them, be it WPML or another.

Regards,

Neil James

@valicesupport,

If you read /docs/block-editor.md in the plugin, an experimental block-editor version is included in this version. It seems that this has had the effect of hiding the description (and also the revision summary box) in the classic version.

If you are able to edit /css/style.css and change lines 18-19 to read #postdiv { and delete lines 51-53 starting #revision-summary { then they will reappear.

Regards,

Neil

@mabuthondlela,

The plugin has been successfully installed.

However there is an issue with your configuration which may lead you to think that it has not been installed properly.

I also had the same issue, and took some time to track it down, so I put this message into the plugin (in Version 3.2.4) which explains the problem.

When the plugin is activated, generally by someone with the Administrator role, the user should see a menu item labelled Documents.

It will put it there if the user has edit_documents capability. The plugin sets the edit_documents capability to True for roles administrator, editor, author and contributor; and to False for every other role.

You get the message at activation because your user is in one of these cases:
a) Does not have the role administrator, editor, author or contributor role assigned to them;
b) Has one of these, but also has ANOTHER role assigned to them.

Why? Because a False value will not allow you to access the functionality evnn if there is also a True value.

You need to review the roles assigned and ensure they are as you need.

Neil James

@torralaq,

You have two requirements to change the permalink:

• Remove the year/month element. This is available with the plugin. It’s the last option in the Settings -> Media -> Uploading Files and is called Document Date in Permalink. Tick it to remove the date element. Note that this is independent of whether the file is stored in a year/month folder.
• Remove the extension. You will require some trivial code to do this. Use the filter document_permalink to remove it (and the period) from the generated permalink.

Note that the delivered rewrite rules support your required format. That is, take a currently valid permalink and remove the date and extension elements and you can use that link to retrieve your document even now.

Hope this is of use,

Neil James

@macheteyeti,

I hope that you have been able to resolve this already, but if not, given your statement that you can upload ordinary media, but get the message that you cannot write to the directory when you try to upload a document, then I would guess that you do not have the correct value for the document directory after the migration.

Please go to your Admin Settings -> Media page. There are a number of values contained in the section Uploading Files.

One of these will be labelled Document Upload Directory. Please check that this is the correct value for your migrated site.

Separately, you have questions about the year/month combination for being a) part of file location; and b) on the permalink.

These are completely independent and one has no impact on the other, though obviously they are related.

For the file location, this is determined by the option Organise my uploads into month- and year-based folders. Your uploads (both Media and Documents will use sub-directories or not. If used, the file will be stored there and the attachment postmeta will contain the sub-directory name. That’s it.

For the permalink, the year and month are used as part of the search criteria to find the document post record to be displayed. Arguably since the unique defining criteria is the post name, and the year/month can only serve to NOT find the record when given as all conditions need to be met for the record to be found. In fact there was a bug related to this. This was one of my motivations to propose the option Document Date in Permalink in version 3.5 that removes the year/month from the permalink.

As a final thought, strictly the year/month on the permalink is that of the Document record and the year/month of the uploaded Attachment record. If they are uploaded around midnight on the 1st of the month, they can validly have different values.

Hope this helps and clarifies,

Neil James