jqz

@rsouzaam

From this core ticket, it seems the issue is affecting multiple plugins.

Sadly, that’s the ticket that introduced the problem, the so-called fix for which was included in 6.7. But it does affect multiple plugins, including WordPress’s own JetPack.

ongoing “Student movement” and a subsequent “Curfew” in our country

Which country? I appreciate your difficulties, but for the sake of choosing software, more transparency would be welcome.

Upscaling an image is really not recommended. It will degrade quality. If you need to make a smaller image fill a larger space, use CSS (e.g. img.mysite-large { width: 100%; }, and let the browser do the upscaling according to the available space, which will be less on phones.

I disagree re error handling. You can detect this issue from the PHP and/or JavaScript code. As pointed out above, when the POST payload exceeds the maximum size, the request is received with the POST data missing. So you could check for that in the PHP AJAX handler and return something to indicate the data was missing (which is suggestive of a POST size limitation issue). And/or you could handle the Error exception in the JavaScript which makes the AJAX request, to abort the upload and report that it failed, rather than having the progress bar stuck on 0.78% (or whatever) forever with no further feedback.

Also as pointed out above, WordPress’s Media Library upload does report an error in a similar situation (albeit a bit vague).

I found it was Apache’s LimitRequestBody setting. I’d based my .htaccess file on one I found elsewhere that had that 2Mb restriction put in place (with a comment that it was to allow large form-data posts – obviously the server it was used with had an even lower restriction), probably from an era where files were not normally uploaded via JavaScript XHR.

So my problem is solved, but some error handling with suggestions for settings to change wouldn’t go amiss to help others who encounter upload size limitations.

It seems that the server has a limit of 2Mb for the size of the request (POST) payload. Anything more than that results in the entire payload being silently dropped (or at least I can’t find where any error is logged), with the request continuing to be processed as if nothing had gone wrong. In cPanel’s PHP settings, post_max_size is 128M and upload_max_filesize is 1G. However, Apache’s LimitRequestBody setting could be having an impact…

Media Library also fails to upload files more than 2Mb, but at least provides a vague error message: “Unexpected response from the server. The file may have been uploaded successfully. Check in the Media Library or reload the page.” Rather than stalling completely.

It would be good if you had error handling for this situation, which must surely be quite common, and perhaps provide a more informative error message than WordPress does.

• This reply was modified 7 months, 1 week ago by jqz.

Successful case has the following $_REQUEST parameters in first AJAX call:

‘action’ => ‘ai1wm_import’,
‘ai1wm_import’ => ‘1’,
‘priority’ => ‘5’,
‘secret_key’ => ‘xxx’,
‘storage’ => ‘xxx’,
‘archive’ => ‘xxx.wpress’,
’em_ajax’ => true,

Failing case has only the first two. Why would the other parameters have gone AWOL?

More info:

When it works, the following hooks are run:

‘Ai1wm_Import_Upload::execute’
‘Ai1wm_Import_Compatibility::execute’
‘Ai1wm_Import_Validate::execute’
‘Ai1wm_Import_Check_Encryption::execute’
‘Ai1wm_Import_Check_Decryption_Password::execute’
‘Ai1wm_Import_Confirm::execute’
‘Ai1wm_Import_Clean::execute’

When it doesn’t, only Ai1wm_Import_Clean::execute is run. Why might that be?

Totally agree. I had a theme that worked well with Events Manager 5.x. But now, with EM 6.4, I’m having to duplicate CSS rules to add !important along with .em.pixelbones in the selector. I’ve wasted tens of hours on this.

I am still thinking of reverting to EM 5.x and never upgrading. For a new site, I thought I’d use the latest (and have now invested time in making it work). On existing sites, I will have to charge the customer hundreds when an upgrade becomes necessary.

We are not allowed to post links here. Please research via MDN or suchlike for why you should avoid using !important at all costs.

The direction you are going is both disappointing and worrying. It is worrying because it seems like you have recruited programmers who have no idea what they’re doing.

The CSS provided by a plugin should be basic, and the minimum required for it to work in any theme.

Please consider separating presentation and content, and providing a separate plugin with the CSS (for those that would like it) from that with the functionality.

Also, please use SemVer (semantic versioning), so that we will have some idea if there could be a breaking change in an update. A potential breaking change requires a new major version number. New features do not, however major they are.

• This reply was modified 10 months, 3 weeks ago by jqz.
• This reply was modified 10 months, 3 weeks ago by jqz.

I remain disappointed.

I cannot wait four months for a response.

I got a quick fob-off reply claiming we have the ‘pro’ version (we do not) and then using WordPress rules (that support cannot be provided for paid products) as justification for not providing support. That was mistaken. But also very poor form. Thinking about it now, I don’t think it was mistaken: it was just used as an excuse not to provide support.

> They must be busy with their existing/pending list of threads

I don’t believe that. They more like;ly, it seems, simply cannot be bothered.

Extremely disappointing. 1* review remains.

I am now stuck with having to reverse-engineer your software to solve a problem of your own making.

I hope others read this thread, so they can be well-advised to avoid your software.

Not only that, they should check with any designers they employ, and make sure they insist those designers don’t use your software. It’s rubbish.

I wouldn’t want anyone else to make the same mistake we made, and hope this review helps some people avoid that pitfall.

Bye.

• This reply was modified 1 year, 6 months ago by jqz.
• This reply was modified 1 year, 6 months ago by jqz.
• This reply was modified 1 year, 6 months ago by jqz.
• This reply was modified 1 year, 6 months ago by jqz.

PLEASE RESPOND.

It doesn’t seem to be an ongoing thread. How long must I wait for the next response there? I’ve waited 3 f-ing months!

I already have created a support ticket – 3 months ago.

Please see the details here:

https://www.ads-software.com/support/topic/how-to-view-markup-for-elementor-page-header-footer/

Any danger of a further response to this?

We do not have Elementor Pro, therefore this is the correct forum for support.

I’d rather not have to reverse-engineer your software, but cannot wait forever for a response to what should be a fairly straightforward question, and one that other users may have too.

Also, we do not apparently have Elementor Pro anyway.

All incarnations of the website have ‘Go Pro’ or similar in the Elementor menu on the WordPress dashboard.

Would you please answer the original question here?